Retropie Pi Zero W Video Enabled Themes with Snaps

[fnkngrv]

So unless my search-fu is failing me I am not seeing much in regards to discussion about video enabled themes in ES on the Pi Zero W. I figured that I would start this thread to share my experiences and what my research nets me to figure out how possible and feasible it actually is to try and have ES themes with video snaps enabled on the board for the community. I have already begun work as of a few days ago. I will update over the next few days.

VLC is the default rendered now in RP as of 4.2.x because of its ability to deal with layers in png files in themes in ES. If VLC is too taxing then I will have to switch to the OMXplayer. I had been told that xvid encoding would work with VLC however I am not so sure that is the case as many times divx can be taking on a CPU depending on the parameters.

[fnkngrv]

I have determined that no matter how low a quality the encode and how small the res using VLC which is now default as of 4.2.x both the video and the audio is choppy therefore I am going to change the rendered to the OMXplayer.

I have also determined that if you have the screensaver set to black then the CPU will idle at roughly 20% avg and 54ish C. Moving over to using the dim setting the CPU will idle at roughly 25% and 62ish C. Moving over to the video screensaver for roughly 15 minutes the CPU stays pegged at 100% and the temp steadily, yet slowly rises. It reached 72 C at the 15 minute mark.

[fnkngrv]

For my first test format I went with AVI 320x240, mp3 128k, Mono, 60fps. Now I know that 60fps is high for this board, but I wanted to build a historical frame of reference.

I am using nmon to monitor the CPU and watch /opt/vc/bin/vcgencmd measure_temp to measure the temp actively. I am attaching below the behavior being seen.

Graphic 1 shows that I booted the Zero to the systems carousel in ES. Switching menus you see the first spike as I going into my NES system. I immediately go into a game before allowing a video snap to parse. I am using lr-quicknes as my emulator. The second set of spikes are the emulator process beginning and then the next several intervals are gameplay. During gameplay I am sitting at around 62-63 C. I have my board in a Pi Cart and have a Microcenter heatsink on the CPU. When I exit the game and go back to ES we see another spike.

At this point I am letting OMXplayer parse the newly created .avi file. With .mp4 files (320x240, AAC, 128k, Mono, 30fps) that I have from my Rpi3 builds it takes roughly 5-7 seconds for the video to begin playing. The .avi file is however a different story. It takes 9-11 seconds before the file begins playing and as you can see the CPU spikes and stays there. After several intervals I enter back into the game and as you can see since the OMXplayer process I am assuming ends the CPU drops. I then exited the game after a short period and then allow for the video snaps to load again however this time I go from the .avi to the .mp4 then go to the main systems carousel and allow the board to sit at that screen for a decent period of time. During this time the CPU does not drop which leads me to believe that the OMXplayer process either hangs or still runs in the background. Also during this time the temp as you can see climbs to 69 C.

I then performed a reboot. As you can see the CPU stays pegged during and then after the reboot sitting at the main systems carousel. The temp however dips back down into the low 60s. I then went back into NES and started 1943 once again which drops the CPU and keeps it at an expected avg % of around 30.

You may ask, "have you captured with your default .mp4 library alone as a baseline?" No I have not as I plan to walk through several encoding patterns and will decide from there whether or not it is even feasible for me to enable video snaps at all. Right now the low res .mp4 that was my original is the benchmark time of 5-7 seconds that I will be measuring against and honestly to me that is too long of a delay.

[fnkngrv]

@pjft Below you will see the results using htop. As you can see even with the CRT theme the CPU immediately pegs the CPU with PID process 640. Then once I leave the system menu and move back to the systems carousel screen the CPU still stays that way until A) the screensaver kicks in (set to dim), B) I enter into an emulator, or C) reboot the system.

[fnkngrv]

@pjft I have opened an issue with the developer of OMXplayer on GutHub and provided my findings so far. He is leaning toward the issue being EmulationStation itself or else whatever is in the current Retropie build image for the Pi Zero, but he is working with me to run it down and try to be sure.

[fnkngrv]

It would appear that the dev of OMXplayer very well may be right that it is not the OMXplayer that is the issue, but emulationstation itself as it hits the CPU hard at 85% when using VLC and between 70-75% with OMXplayer. I am not sure where to report this to for further troubleshooting.

VLC

OMXplayer

@pjft do you have any input on where to go next with this issue?

[fnkngrv]

I may have spoken too soon. I didn't have both ps aux and htop running at the same time. Now with them both running you can see that something is not right as well with OP as there are multiple instances open? Could it be that ES is making multiple calls for the OP process to run??

[pjft]

@fnkngrv Thanks for looking into this.

One comment: it'll be easy for you to test your hypothesis of " During this time the CPU does not drop which leads me to believe that the OMXplayer process either hangs or still runs in the background." by running "top" or "htop" (which you need to install separately) and see if, effectively, there is a leftover OMXPlayer process hanging there.

Looking forward to seeing your research.

It seems that VLC is unusable, but OMXPlayer still lags a lot while loading the videos. Interesting.

Thanks!

[fnkngrv]

@pjft said in Retropie Pi Zero W Video Enabled Themes with Snaps:

@fnkngrv Thanks for looking into this.

One comment: it'll be easy for you to test your hypothesis of " During this time the CPU does not drop which leads me to believe that the OMXplayer process either hangs or still runs in the background." by running "top" or "htop" (which you need to install separately) and see if, effectively, there is a leftover OMXPlayer process hanging there.

Looking forward to seeing your research.

It seems that VLC is unusable, but OMXPlayer still lags a lot while loading the videos. Interesting.

Thanks!

I'll see what I can find out and report back for sure. Thanks for the input!

[fnkngrv]

I do intend to provide further findings as they come along. I spent much of the last day reading the thread on the omxplayer project on github under reported issues and feature requests. It appears that the CPU spike and pegging is a known issue with OPand there have been those that have managed to debug and find that the process for omxplayer.bin actually shows up dozens of times if not more simultaneously. This makes me very curious to see if I switch my renderer to OP rather than VLC on my current stable Rpi3 build. From what I have seen this issue has been occurring for well over a year and multiple versions which makes be curious as to why it has not had much consideration by the developer. Most that I see have abandoned OP due to this for video and kept it strictly to audio playback or streaming.

[fnkngrv]

I have been in discussion with the dev for OMXplayer itself further and he is digging into it. Not sure if I have shared as of yet however my request on GitHub with him is below.

OMXplayer Issue 551

[pjft]

Thanks, and thanks for the research here.

Just to confirm: I don't expect this to be a zombie process thingie, as suggested in that bug report/thread. To the best of my knowledge, all child processes are explicitly removed from memory after the process exits.

Let us know what comes out of it!

[fnkngrv]

The last that I heard from the dev he was able to replicate the issues while inside of ES. His plans were to test outside of ES. I have reached out for an update.

[peter_shaw]

bringing this thread back from the dead, as i encountered the same issue on my pi zero. any updates?