Help testing: Random Video Screensaver on Main Branch

[meleu]

@pjft tested here. Everything seems to be fine. Here is a screenshot to let you see how the name is displayed:

One thing that worth to mention: while the video is playing and I press right-arrow key, the screen goes back to ES and then fade to black and then starts the next random video. Not a big problem for me, though.

[pjft]

@meleu thanks for both reports!

A question: can you go to the video settings and set video quality to highest (default should be native) and medium and see how the performance goes? It won't affect the video quality per se but the game name should be better defined.

Also, well spotted. Pressing right should move to a next video, and pressing X (PlayStation controller) or Start should launch the game being displayed.

That being said, you're right: with VLC there is a long fade out animation that won't look right. I will fix that so that the transition is smoother.

Thank you!

[meleu]

@pjft said in Help testing: Random Video Screensaver on Main Branch:

A question: can you go to the video settings and set video quality to highest (default should be native) and medium and see how the performance goes? It won't affect the video quality per se but the game name should be better defined.

I changed to highest and then the game name isn't displayed:

Changed back to Native and the game name is displayed as that After Burner screenshot.

[pjft]

@meleu Hm. Thanks for testing.

I just pushed a build that should perform better in changing between videos when you push "right" - please test if it works as intended.

What about "Medium" quality, does that work well for the captions?

I'm stumped about the "Highest" quality not rendering captions - does that happen for all videos?

Thank you good sir! Hope your little one feels better.

[pjft]

Actually, I just added a few more options there. If you could test them out and see which work with the game name, which don't, and if the video runs smoothly, that'd be perfect.

Thank you!

[Hex]

@pjft. Just tested it and its working well. Also I think native should mean native resolution of screen/FB and not video.

Edit: On linux

[pjft]

@Hex Thanks. Could you test the captions across all resolutions, as well as video performance?

How about "Display" and "Video"? Or what should we name it? I'd want to keep the names small, so open to suggestions at this stage.

Thanks for testing it out!

[Hex]

@pjft Captions work as expected Highest : 1080p, High : 720p

Yes those are good suggestions.

[pjft]

@Hex thank you.

Just to confirm, then: if captions work as intended on highest and if the video doesn't stutter on highest (if it performs well) then I may even just remove the option altogether, or just leave two options: high and low (one being the full display resolution and the other the video one, upscaled, for weaker devices).

Let me know.

[Hex]

I am testing on Linux. I dont have my pi3 with me. I dont think there would be any stuttering on VLC even on 2k resolution.

[pjft]

@Hex Thanks! Not a bother, I'm just looking for the Linux experience with VLC. The Pi uses OMX Player anyway, so that I can test.

If it works well on the highest resolution with and without captions, I may even just remove the option altogether and default to highest anyway.

[meleu]

@pjft IMHO an option for a weaker hardware (even x86) is always welcome.

[pjft]

@meleu Sounds good. I think that's probably wise. But I'll leave it with just two options then - "fast" and "HQ".

[pjft]

Ok, so a final update.

I've just updated the rebased branch with:

• Only two options for VLC screensaver quality (only visible in non-Pi devices): "high" and "fast". Default is "high".
• Added "stretch" option to VLC screensaver as well (so it can keep video proportions). It's "off" by default.
• Option name stays "Random Video" at the moment.

Would appreciate one final round of testing on Linux and the Pi, just to confirm I'm not missing anything.

Thank you!

[meleu]

@pjft I'll try to break test it tonight. ;-)

[Hex]

@pjft same here. Will report back in the evening

[pjft]

@meleu said in Help testing: Random Video Screensaver on Main Branch:

@pjft I'll try to break test it tonight. ;-)

Why don't you even... -

Thank you both. :)

It's end of day here, so I'll adjust anything missing or messed up tomorrow.

Thanks!

[pjft]

Just updated the branch one final time. Had forgotten one line after merging with the OMX audio changes.

@Hex One small comment: the forced audio init/deinit on every OMX Player instance causes a slight but noticeable delay.

I notice that if I remove the init/deinit code that it works just fine on my end (I'm using "both"), and from my testing it only failed to show any video when using the ALSA:HW:1:0 option, so I'm assuming that it is only necessary if the actual option is this one? Would that be a correct assumption? Or maybe the other ALSA option also needs to be catered for? Or maybe it depends on the ES audio settings as well, and any conflicts between those and OMX ones?

Anyway, my recommendation would probably be to only use the init/deinit instructions explicitly only when we actually need to force it to use the same device, as it causes a slight slowdown when changing/loading videos, but also cuts short the navigation sounds if the theme has them, especially when scrolling quickly (i.e. keeping down/up pressed).

If you tell me that it's only with the ALSA ones (or better, even only with the ALSA:1,0 one) I'm happy to add the conditional statement on my PR, so it only runs that code when it is actually needed.

Alternatively, if it'll be a bit more complicated, you can probably submit a separate PR for that, it's not a big deal but it's one we should perhaps tweak if possible.

Let me know.

Thanks for all the work here as well!

[Hex]

@pjft I will need to test it. Can I let you know later in the day?

[pjft]

@Hex Sure, please. If you want to look into that on your own time as well, and then submit a PR it's perfectly fine - just wanted to mention it in case you would be able to provide an answer off the top of your head, given that you were the one who researched all of that.

It's not urgent nor is it a big deal - in fact, it's right now in the main branch. It's just a small - but noticeable for those who had been using OMX Player - delay in loading the videos and navigating, so while it will be needed for those cases where you do have an external sound card and are competing for the ALSA driver, I'd rather not have it for all the other cases where it's not needed, just that. :)

In fact, we could probably be sneaky about it and just de-init the ES audio completely when:

• the user navigates opens the gamelist, if it is a VideoGameList; and
• if the user is running OMXPlayer and
• the user has the ALSA:HW:1,0 selected (or whatever conflicting options there'll be)

given that, truth be told, if they're on the gamelist and it has videos, it will likely be permanently running OMXPlayer anyway and the audio channel will need to be allocated to it, if it's conflicting.

That would probably save a bit of CPU time in de-initing and re-initing on every single new video being shown.

Obviously you'd need to make sure that you'd re-init the audio when you leave the gamelist (either to the system view, or to a gamelist view that's not a Video one).

Just a thought.

EDIT: as I said, it's end of day for me, so do take your time. I'm in GMT+1 time zone, and tomorrow is a work day.

Thanks!