Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

  • 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.


  • 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.


  • 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+.


  • 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.


  • 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.


  • 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.

  • Global Moderator

    @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 ?


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


  • @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.


  • 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? :(


  • @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.


  • 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...

  • Global Moderator

    @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.

  • Global Moderator

    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 ;)


  • 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...

  • Global Moderator

    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?


  • 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


  • @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.

  • Global Moderator

    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?


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

Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.