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

matchaman

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

@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

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

pjft

@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

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

@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

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

@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

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

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

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

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

@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

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

@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 :/

matchaman

Update:

I had the audio almost off and didn't notice something very serious once omxplayer runs inside ES: not only omxplayer remains stuttery outside ES but the whole system slows down like it's heavily underclocked! This is getting weirder...

Sorry for the length of the video but I explain it here in practice:

pjft

@matchaman I can't watch any of the videos for the moment, but that's good then. Can you SSH into it and run"top", and see what exactly takes up the CPU when you play a video?

matchaman

Here's a capture of top before omxplayers runs inside ES:
alt text

And another afterwards, with what appears to be system-wide slowdown:
alt text

mitu

@matchaman Why is there a python process keeping the CPU busy ? Do you have a BGM script running ? Are there any errors reported by dmesg after the slowdown ?

pjft

@mitu @matchaman well spotted, was going to ask the same (didn't know about the bgm music script using python though).

The system does not appear to be in significant load though.

Can you install htop and run htop instead of top to assert the process trees?