Please test: Using OMXPlayer as video renderer

Nismo

@MWGemini I already started to upload media packs on this thread: https://retropie.org.uk/forum/topic/8019/oldroom-theme-w-i-p-media-packs

I'm encoding the videos at 480 max width resolution and 25fps. Can you download some of them and test with VLC renderer? since my theme has a lot of overlays and need VLC renderer to fully work.

I hope the temps will be ok now with that values and vlc renderer...

MWGemini

@Nismo The VLC player is the one that has the temperature problems. The new version uses OMX. I'll try to set aside some time to test your packs, but it might not be until the middle of next week, as I have to help a friend move this weekend.

Nismo

@MWGemini As far i know, in the new version you can select what video renderer to use (VLC or OMX) inside es_settings.cfg.

@fieldofcows said in Please test: Using OMXPlayer as video renderer:

On Raspberry PI the player can be switched between VLC and OMX using this option in es_settings.cfg:
<bool name="VideoOmxPlayer" value="true" />
Setting the above to false makes ES use VLC as it does in the current version of ES. The default is 'true'.

When using OMXPlayer as the video player it is not possible to render anything on top of the video (like the raster lines in the oldroom theme). This is a limitation currently of this rendering method and unlikely to be fixed. Switching to VLC re-enables overlay on top of video.

Also, I'm not sure if every video format that VLC supports is supported by OMXPlayer. You may have to convert some files.

The binary is RPi 2/3 only at the moment. The binary will not work on RPi1 but building from source might just work.

Get it here:
https://github.com/fieldofcows/EmulationStation/releases/tag/v0.3-RPi-6

Like @fieldofcows said here, people who want to use overlays the must stay with VLC video renderer.

I was reading a few comments about temperatures and different resolutions and fps, and I think with that videos the temps will be ok, but I can't test by myself.

I think people with themes wich requires overlays would be very happy with they can play my videos with not so high temps, they are highly optimized.

Thanks for your help testing, and don't worry, take your time.

fieldofcows

I'm not entirely happy that we've one player that supports overlays and another that does not so I've been trying to find a way to either get the OMX player to support overlays or use some other way of bringing the CPU/GPU usage down.

Unfortunately my RPi3 died (not from overheating due to videos I hope :D ) so I'm not making much progress at the moment...

pjft

@fieldofcows Oh no, I'm sorry to hear that :(

I still like the option being left to the player, as some themes (maybe most) will not require overlays (carbon, etc), and the start/select menus can still be mitigated by just stopping the movie when triggered as a workaround.

Anyway, thanks for the great work!

Nismo

@pjft There are not too much themes with overlays because video support it's vey new, but i'm sure themers will use that feature soon. There are almost 3 themes that uses overlays right now: oldroom theme, CRT theme, and oldTV theme. As well pixel theme with video support and carbon theme with video support displays wheels on top of video (only a bit).

@fieldofcows I'm sorry so much to hear that, unfortunately I have no job now, and can't contribute with money, but if you open a paypal account maybe some people want to donate to buy a new one for you.

I'm uploading optimized videos for better temps in oldroom theme thread. If you buy a new one, please use my videos for better temps.

Regards.

fieldofcows

@Nismo said in Please test: Using OMXPlayer as video renderer:

I'm sorry so much to hear that, unfortunately I have no job now, and can't contribute with money, but if you open a paypal account maybe some people want to donate to buy a new one for you.

I think it's my own fault. It was sitting on my desk happily running and I needed some room so I shoved everything backwards and I'm guessing something shorted out. I should really put it in a case.

I do have another but it's sitting in here.

I might have to dig it out before I order another.

Nismo

@fieldofcows Beautiful mini bartop, I like so much. I think you should use a cover for the speakers.

Yes it's useful to have the rpi inside a case, for things like this, and other things. Anyway I suggest to you the donate thing, maybe you can open a thread for that in "help and support" forum.

I hope this issue don't stop you from still making your amazing work.

I have a question for you because yesterday I was having problems with another emulator because the double backslash, but I think it's better to send to you an email to speak about that. Maybe in the near furture, i'm very busy with the theme and media packs right now.

Regards mate.

pjft

@fieldofcows On omxplayer and layers, found these two items which may be helpful:

https://www.raspberrypi.org/forums/viewtopic.php?t=25866&p=242453

and

https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=109557

on setting the OMX display layer, which may help. I don't know how you're calling omxplayer, but there's also a layer option in the command line.

http://elinux.org/Omxplayer

Kodi does allow the user to render a GUI on top of the video (for video control), so it should be doable, technically. I wonder if you can just bump the video completely to the background, and just render a transparent section on the theme on the area where the video is meant to be displayed.

My 2 cents.

Thanks!

fieldofcows

@pjft Yes, thanks for that. I'm already setting the omxplayer layer to ensure it renders along with SDL. The problem is we need to render some items behind the video and some in front and we're not in control when each frame is rendered. This means that we need to use two layers in our SDL rendering.

Unfortunately the SDL we are using does not allow you to play with the rendering layers. It's hardcoded at 10000.

pjft

@fieldofcows oh, got it. You have no control over the individual layers of the theme in order to add the video in the middle, is that it?

So, here's a suggestion which was what I tried to describe earlier - I'm unsure how feasible it is, so I wonder if it's doable:

move the video to the background
when rendering the theme on top of it, force a fully transparent area to be rendered on the video area, creating effectively a "hole" in the theme's background. You may need to process the background image on load to turn it into a transparent background with that area unfilled.

Conceptually/hopefully that could work without too much overhead? Once again, if it's feasible.

Apologies if it's something you already tried or that you know won't work. I'm just trying to think of the problem differently, even though I lack all the context of the implementation here.

Thanks for looking into this! Have a great weekend.

Nismo

@pjft As far I know, the problem is that the video it's rendered on top of all, and you can't move the video to the background.

pjft

@Nismo oh. I completely misunderstood what we didn't have control over then.

fieldofcows

@pjft said in Please test: Using OMXPlayer as video renderer:

So, here's a suggestion which was what I tried to describe earlier - I'm unsure how feasible it is, so I wonder if it's doable:

move the video to the background
when rendering the theme on top of it, force a fully transparent area to be rendered on the video area, creating effectively a "hole" in the theme's background. You may need to process the background image on load to turn it into a transparent background with that area unfilled.

Good idea! But I've already tried it. The problem is that the way the layer is setup by SDL completely covers any layers below it. I set the video to render below the SDL layer then actually stopped ES from rendering anything and I still didn't see the video.

If I could get hold of the dispmanx handles from SDL then I could experiment a bit further but I would have to use internal SDL structures to do this which would make it fragile when the system is updated.

pjft

@fieldofcows Got it, that makes sense. Thanks for elaborating.

And I assume that it would be extremely hacky to separate the rendering of the video overlay layers from the rest of the theme, so that you'd render everything from the generic theme using the standard 10000 SDL definition, then you'd render the video on 10001 or something, and then force render the overlay elements only separately on top of the video?

I was looking through the code but couldn't find much. Still, I like the way you used omxplayer to render the video - it's smart and effective.

A suggestion, after searching for the code, and then doing a couple of Google searches. Read the following thread for inspiration:

https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=101383&p=702598

Would it be feasible to just not render the overlay on the current ES rendering pipeline, but just use something like

https://github.com/AndrewFromMelbourne/raspidmx/tree/master/pngview

and execve it to render the image on a layer on top of the video, at the designated x and y coordinates?

I know it's hack-ish, but hey. Just trying to help out and think about options.

If I do have the chance (which I doubt, unfortunately, as everybody is sick at home...) I'll try to get your ES build with OMXPlayer to run a video, and then via SSH attempt to run this PNGview thing on a layer further on top, hoping that we can take over the rendering pipeline.

Well, just a thought. Thank you so much for thinking through this, though.

BuZz

Some more solutions

statically link with upstream vlc with h/w acceleration enabled (Will add significant build time etc).
not worry for now until h/w acceleration is included in Raspbian by default (the next version I should think).

I don't think it's a major problem anyway for now.

I may at some point include upstream ffmpeg builds as a module, which could be used by attractmode / retroarch etc. Perhaps ES could utilise them (would obviously need to use the probably lower level ffmpeg api rather than vlc's), but you would have the increased buildtime of emulationstation. Waiting seems a good option :-)

pjft

Agreed, it's certainly not a blocker nor a big deal. I suppose, if people are using 480p videos (I believe the HQ videos from EmuMovies are in that resolution) it can certainly degrade a bit the performance, or not render without artifacts (480p@60fps) but there are workarounds, for sure. It's certainly a good perspective.

A question on your second bullet, though, just to clarify. What would that entail/how would that ultimately influence these developments? Would that mean that "out of the blue" the same build would certainly start working, as the VLC being called would suddenly default to HW acceleration?

Or how do you envision its applicability in ES and its development?

Apologies if it sounds naive, but want to understand better how these intricacies work, if you do have a moment to spare. :)

BuZz

@pjft It might need a code change to enable the h/w decoding - I don't know as I've never used the vlc library api.

fieldofcows

@pjft I guess the PNG thing would work but it would be less than ideal and imagine would result in other rendering bugs (such as rendering on top of the menus, etc.) that would all have to be sorted out.

Currently I'm approaching this from a different angle. I don't see any reason why we can't pull the source in for omxplayer, patch it a little bit then build it as a library. This gives us some flexibility then with the rendering.

What I would do is provide a patch to modify the rendering pipeline to render to an EGL texture rather than directly to the screen as omxplayer does at the moment. I could then use the existing VLC-based video code to render in ES maintaining overlay support, etc.

This is all theoretical at the moment because I don't know a great deal about the HW acceleration beyond what I read at the weekend. I might try giving it a go later but I need to extract my pi from my bartop cabinet because I've destroyed my development pi :(

BuZz

@fieldofcows This sounds like too much work vs reward - relying on a patched omxplayer etc - and more to maintain.

If going that route it might be better to just build against upstream vlc/ffmpeg with acceleration.

(Although as I said, I think it's better to wait).