Bug (solved): OMXPlayer on Stretch-based builds stutters on composite

matchaman · 31 Mar 2018, 22:46

This is definitely a bug. While videos (and screensaver video playback) work fine when the device outputs on HDMI, apparently that's not the case with composite (any sdtv_mode).

There's heavy stutter that made me disable OMXPlayer for now. It definitely didn't happen with my old setup (Pi 3 with RP 4.3) but I can't check with my previous model since I sold it, so I can't verify if it's a hardware issue.

Any ideas?

Edit: many things have been discovered since I made this topic. The basic issue here is that once omxplayer runs inside ES, the whole system slows down, including emulators and videos. It happens only on Stretch-based builds, affects all Pi models and ONLY when composite video is used.

Edit 2: Finally, the problem has been identified. It's the -o both parameter on omxplayer causing some kind of driver incompatibility on Stretch. A simple fix is to set it to ALSA:HW:0,0 instead on ES audio options.

pjft · 1 Apr 2018, 07:21

OMX player is a native video player that relies heavily on the system libraries. There isn't much ES-specific that would likely affect it, but we can explore that together.

Are you comfortable with the command-line?

If so, would you try exiting ES and running omxplayer to play any of your videos and see the behavior outside of ES?

Then try to run the same experiment forcing layer over 10000 while ES is running. See if the behavior changes.

To confirm, the exact same setup when HDMI mode works well, is that it?

Best.

matchaman · 4 Jan 2018, 11:18

Thanks for the reply. I just opened a video from the shell via OMXPlayer and the jagginess is still a thing on composite.

I also tried with --layer 10000 (outside ES, not sure how to do this within ES) and the problem persists.

I'm expecting a friend with a Pi 3 to test if this is hardware related to the 3B+.

matchaman · 1 Apr 2018, 11:19

Just tried out my microSD on a Pi 3. The problem is exactly the same. This is solid proof it has nothing to do with the B+ model hardware, while OMXPlayer has the same issue regardless of running on ES.

I conclude that this is an OMXPlayer bug and a quite bad one for people who use composite.

pjft · 1 Apr 2018, 14:19

Thanks for testing.

So, while this seems to have narrowed down the issue to omxplayer, my searches on Google don't seem to find any reference to such issues, so if like to suggest at least two options.

The first would be for you to update the omxplayer package and see if it improves the behavior.

The second would be, if you have an empty SD card lying around, to install a fresh image of RetroPie and run the same test. If it still occurs, install a fresh image of the official Raspbian distribution and test again.

If it still happens, I'd file a bug here:

https://github.com/popcornmix/omxplayer

But I'd hope it'd be a mix of configurations or outdated packages. Hope being the key word here. :/

It might also be that there's a specific player option that'd improve it. See:

https://elinux.org/Omxplayer

In particular the interlacing ones, see if any makes a difference, but try out others. If you find an option that works I'm happy to add that to ES either as a default or if there are any issues with it, as a video option.

Do keep me posted, and best of luck.

matchaman · 4 Jan 2018, 16:43

OMXPlayer doesn't seem to have been developed for about a year. I tried updating and it appears I have the latest version dated mid-2017.

I finished making a brand new install of the RetroPie v4.3.15 test image and I uploaded a set with videos. Same problem :/

I also made a fresh one for my friend's Pi 3 model with v4.3 stable and the videos play fine with the same version of OMXPlayer.

It's definitely something that happens with the test image and it has not been fixed by any update yet.

mitu · 4 Jan 2018, 17:24

@matchaman The new image does have anything special - from what is supplied by Raspbian - that would affect omxplayer. Can you try installing Raspbian Stretch directly and test it with a video you have ? Do you get the same problem ?

matchaman · 4 Jan 2018, 17:52

I'll do that soon. Meanwhile, can anyone please report if it does (or doesn't) happen in their setup?

pjft · 1 Apr 2018, 18:11

@matchaman I don't have composite, so I can't comment much, but I'd expect that it's either Stretch related or config.txt related.

matchaman · 4 Oct 2018, 22:15

I tried today with a brand new Raspbian (stretch) image. Videos do not stutter at all on omxplayer (outside PIXEL desktop). Same settings, brand new RetroPie 4.3.17 test image, same stuttering problem.

Both cases on Pi 3 and 3 B+, zero difference... while stable RP 4.3 shows no problems at all.

What's going on? :(

pjft · 11 Apr 2018, 06:41

@matchaman so, plain Raspbian works well, RetroPie image stutters, is that it? Interesting.

Things to consider:
Compare config.txt
Check omxplayer dependencies and compare versions across both (dependencies and omxplayer)

I'm assuming it's the same hardware you're running it on.

matchaman · 11 Apr 2018, 16:59

I kept checking that settings were the same and then I used the exact config.txt out of paranoia :p no change...

I tried checking dependencies with ldd /usr/bin/omxplayer but I get "not a dynamic executable" on both setups. As for version, both are the same (latest from July 2017).

And yes, it's both a model 3B and a 3B+ and always these two particular units. Before getting back a 3B model I thought it had to do with the hardware which is not the case...

mitu · 11 Apr 2018, 17:05

@matchaman said in Bug: OMXPlayer on 3B+ stutters on composite:

I tried checking dependencies with ldd /usr/bin/omxplayer but I get "not a dynamic executable" on both setups. As for version, both are the same (latest from July 2017).

omxplayer is actually a shell script wrapper around the omxplayer.bin, so that's why you get this message.
Can you check if you have the same kernel on both systems ? uname -a should show it from a command line.

psyke83 · 4 Nov 2018, 18:15

It seems highly likely that the new 4.14 kernel is the explanation. Jools' testing builds include the new kernel (which is upgraded via a standard apt-get upgrade), but I'm guessing that the stretch or stretch lite image/installation is still using the 4.9 kernel.

I suggest checking the kernel revision on both builds:
uname -a

Edit: @mitu beat me to it ;)

matchaman · 11 Apr 2018, 17:20

On the Raspbian setup I get:

Linux raspberrypi 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv71 GNU/Linux

On RetroPie I get:

Linux retropie 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv71 GNU/Linux

As for the dependences with omxplayer.bin I'll have to compare by taking photos of the screen, which I'll do shortly.

Meanwhile, could anyone please check with composite? I can't be the only user that uses composite for 240p on a CRT...

psyke83 · 4 Nov 2018, 18:32

Unfortunately I don't have a cable to check.

See these lines: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/supplementary/emulationstation.sh#L282-L289

Can you try to comment those lines (that are added via the iniSet function) from your /boot/config.txt and reboot?

matchaman · 4 Nov 2018, 19:00

Big discovery!

I exited EmulationStation with F4 the moment I booted into it (without entering a system). When I tried omxplayer, the video plays smoothly! Then I entered ES again, browsed for a moment, went back and stuttering came back as usual.

Here's a video I just recorded:

Something runs along with omxplayer and makes it run slow. What's completely crazy about this is that when I use HDMI, everything runs perfectly:

@psyke83 just edited these out, I'm getting the good old white screens of death :P

pjft · 11 Apr 2018, 17:58

@matchaman I wonder whether the GPU split changes things for you, and/or whether installing ES on the fresh image manages to replicate the issue.

psyke83 · 11 Apr 2018, 18:01

Please check behaviour without the lines in config.txt, as I asked, but also, I notice that the issue starts occurring after video playback starts inside ES itself when you returned to ES. If you disable omx support in the ES menu, does it clear the bug when launching omxplayer via the shell the second time?

matchaman · 4 Nov 2018, 19:25

@pjft this is a brand new image I installed yesterday again, the only thing changed is that I uploaded my media overnight and my theme (which is basically carbon video).

@psyke83 I disabled the gpu_mem lines, altogether and one by one. Nothing changed except for 1024=256 causing a "white screen of death" (occurred on both units).

I disabled omxplayer for ES (both themes videos and screensaver), rebooted, looked around systems (videos run fine but browsing feels a bit slow which I believe is normal without omxplayer), exited ES, video runs great again on omxplayer.

Something makes omxplayer stutter once it runs inside ES and only when the output is via composite (any sdtv setting). Via HDMI on any resolution, this issue does not happen at all. But what could it be? It definitely didn't happen on 4.3 stable with all updates last month :/