Looking for log/clue why ES video screensaver may get stuck w/black screen

roslof

@mitu said in Looking for log/clue why ES video screensaver may get stuck w/black screen:

@roslof So, it was the video file ? Can you upload it somewhere ?

You got it, mitu. The. mp4 from the log pointed me to several video files encoded with C.E.S. YUV 4:4:4 instead of 4:2:0. An issue you've probably seen here before. Scraping videos can lead to this problem.

I thought I had converted all of the bad eggs to the compatible format, but I just learned (by experimentation) that the script I used from this thread doesn't handle nested video subdirectories. Of the 300-400 videos, so far I've found about a dozen problem children....

With EmulationStation, a common side effect of a 4:4:4 video is that it will only play sound (black screen) but frequently, the same video will immediately freeze/jam and prevent input. Hardware accelerated (OMX) or not, they are trouble.

Assuming you'd still want a file, I'll post a one shortly and update this thread.

Cheers!

mitu

@roslof said in Looking for log/clue why ES video screensaver may get stuck w/black screen:

Assuming you'd still want a file, I'll post a one shortly and update this thread.

Yes, I still want to take a look at it - no rush though, when you have time.

roslof

@mitu here you go:

https://drive.google.com/drive/folders/1vsUqwdCPDRwgF-t-5gO6OY4Kfmh0EYXo

You'll find two videos: A YUV 4:4:4 and a converted YUV 4:2:0.

~~Video is from a C64 game named "Booty". Figured we could use an immature giggle right around now.~~ EDIT: These two files were both 4:2:0... Added Dig Dug video files instead.

mitu

Hm, they both look as YUV 4:2:0 here:

...
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Booty (Europe) (GOOD for ES - CES YUV 4-2-0).mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    creation_time   : 2020-09-25T12:57:11.000000Z
    encoder         : HandBrake 1.3.3 2020061300
  Duration: 00:00:37.06, start: 0.000000, bitrate: 210 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p (tv, smpte170m/smpte170m/bt709), 320x240 [SAR 1:1 DAR 4:3], 44 kb/s, 24.96 fps, 24.92 tbr, 90k tbn, 180k tbc (default)
...
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Booty (Europe) (BAD for ES - CES YUV 4-4-4.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 1
    compatible_brands: isom
    creation_time   : 2019-08-21T18:44:41.000000Z
  Duration: 00:00:37.04, start: 0.001000, bitrate: 347 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 320x240, 218 kb/s, 24.27 fps, 25 tbr, 90k tbn, 50 tbc (default)

They both also work fine with omxplayer, so I think the issue is not the codec. VLC stutters at the beginning of the 'bad' video, so I wonder if it discards some video frames at the beginning of the video and that gets the video player stuck. I'll have to test in EmulationStation to see how it behaves.

roslof

@mitu said in Looking for log/clue why ES video screensaver may get stuck w/black screen:

I'll have to test in EmulationStation to see how it behaves.

Ugh. I hate to be the spreader of bad information, but looks like I did.

First off, I uploaded two (2) new videos: Dug Dug (Europe) and confirmed one is definitely 444 and the other was fixed.

The 444 video renders as I described in ES (libvlc)...
...but I'm more than embarrassed to see that the 444 video plays in ES with omxplayer... Major egg-on-face here. I've been going with what I learned about this format in the past, and clearly it is working now. Please don't tell me it was fixed or a work-around was found more than a year ago...

On the bright side, after converting the 444 videos to 420, my black-screen issues (libvlc/screensaver) have gone away after several hours of run.

mitu

@roslof said in Looking for log/clue why ES video screensaver may get stuck w/black screen:

First off, I uploaded two (2) new videos: Dug Dug (Europe) and confirmed one is definitely 444 and the other was fixed.

Yes, the Dig Dug bad sample fits the bill. I'll try to see it how it behaves in ES.
One more question - what's the version of the vlc package you have installed ?

roslof

@mitu said in Looking for log/clue why ES video screensaver may get stuck w/black screen:

One more question - what's the version of the vlc package you have installed ?

revision 3.0.10-0-g7f145afa84

mitu

@roslof said in Looking for log/clue why ES video screensaver may get stuck w/black screen:

revision 3.0.10-0-g7f145afa84

I'm testing with the lastest version available (3.0.11-0+deb10u1+rpt3 at this time). Adding the video to one of the games doesn't have any issues (just a blank video), I'll have to try the screensaver behavior.

I know the latest version fixes an issue with certain videos locking VLC and EmulationStation (reported a while back after RetroPie 4.6 was released).

mitu

I gave the screensaver a test and included the bad Dig Dug video (yuv444p), but it didn't do anything special in EmulationStation and it didn't lock it. It showed a black screen and then just went over to the next video. During a 10 hour run, it was randomly picked about 40 times.
You can try updating the vlc package and re-try testing with this particular problematic video. I've left a command running in the background to check which video is played by checking every 30s (the screensaver duration) and log it to a videos.txt file

while true; do lsof -p `pidof emulationstation`  | grep 'mp4$' | tee -a videos.txt ; sleep 30; done

roslof

@mitu Nice! I went ahead and upgraded yesterday, but also replaced the 444s and I've been stable. I still have a microSD with the 444 videos and vlc 10. I'll give it a run and confirm whether or not it was an issue with 10, fixed in 11.

roslof

@mitu using 3.0.10 and ~1,000 c64 videos, I've had five (5) black screen freezes so far. My old friend Booty (Europe).mp4 came up three times (not 4:4:4). Two other videos also failed. I am going to update vlc and run it again.

I confirmed in the log that the three (3) videos never rendered, but broke on the first run.

The video.txt dumps and videos are here.

I ZIPped the videos, in case Google manipulates .mp4s upon upload.

I'm updating vlc to 3.0.11 now and will run again. Hopefully the three offending videos will pass this time.

Another interesting thing: Note in the details of each test the number of times "Little Computer People" shows up. Statistically not close to random, since it shows up overwhelmingly more often than the other videos. This did not surprise me, because after watching my screensaver for a couple of years, I've long suspected I was seeing a particular video more often than any other. An Amiga video with terrible music. ;-) Not the end of the world, but noteworthy.

roslof

I'm now testing 3.0.11, using the same videos and ES already played the "Booty" video successfully. This was never successful in today's tests with 3.0.10. It's still early in the run, but I'm feeling confident that latest VLC handles the black screen issue. Will let it soak...

EDIT:
Test is complete. All three videos properly rendered with a normal run of the video screensaver. Some videos were randomly picked more than once.. 4:4:4: files appeared to render black as expected and need to be converted, but they do not freeze the vlc player.

vlc 3.0.11 specifically seems to solve all my video/freeze problems.

The only anomaly now is ES's random video selection. The "Little Computer People" video was chosen WAY more often than anything else in every test. Nothing noteworthy about the video. Suspect ES's random number generator or its implementation is a little funky.

But I'm 100% stable now.
Thank you @mitu

mitu

@roslof Thanks for the tests. The random selection might have an issue, I remember looking at it some time ago and nothing wrong popped up.

roslof

Re: Looking for log/clue why ES video screensaver may get stuck w/black screen

Closing the thread on this. There is nothing wrong with the randomizer. While there was exactly one (1) "Little Computer People" video, there were ~100 variations of the game in the XML referencing the same video. So it's probably by design. It would seem that each game listed in XML with a valid video has the potential to play. Like throwing 100 tickets into a casino raffle drum... You're more likely to win.

Ideally each video found should act as 1 potential. Not a big problem, but since games with multiple variants that reference the same video are more likely to play, making things seem less random than they truly are.

Mystery solved after spending way too much time staring at random videos.