Please test: Using OMXPlayer as video renderer

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

BuZz

I'm happy to buy you another rpi3 from the project donations btw (if you want).

pjft

@fieldofcows Got it. I can see how that could be a pain, monitoring all input events to display and hide the texture depending on navigation and menus. Well, it was an interesting exercise in theory :)

If you're considering pulling the source from omxplayer, would it make it less cumbersome just to follow @BuZz 's suggestion of statically linking with upstream vlc with hardware acceleration enabled, and using your VLC code, seeing if there's an improvement?

After having compiled mame a few times this last weekend during the 4.1 upgrade, I can't think it'll become as painful as that. ;)

@BuZz Thanks for the clarification.

@fieldofcows @BuZz Happy to contribute to that as well if you want. I can make another contribution to RetroPie for my part. Seems fair to say the least.

MoebiuZ

Why not using OpenMAX libraries to decode and render to texture instead interfacing with omxplayer? That would solve the overlay issue.

https://www.raspberrypi.org/forums/viewtopic.php?t=6577

fieldofcows

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

I'm happy to buy you another rpi3 from the project donations btw (if you want)

Thanks BuZz but I've just ordered one - should arrive tomorrow. I don't need donation money for it. I've bought a case for it as well so hopefully won't short this one out :)