0
AnonymousPi

MPV video playback - not showing controls

Recommended Posts

Hi All,

 

Does anybody have a solution to the issue with playing video in Armbian that the MPV on-screen controls (i.e. Pause, Stop and the Timeline) isn't visible in the bottom middle of the video frame? Is there any way to get this back?

 

Does it require a re-compile of mpv, or is this behaviour a result of the All winner undocumented blob based hardware acceleration, dumping pixels straight onto the frame buffer, with little one can do about it. Has anybody compiled mpv from scratch and not had this issue? 

 

I notice that when playing video, the video paints over the top of everything - including the mouse pointer.

 

Photo attached with red boxes to highlight what I mean.

post-1936-0-86265100-1476914747_thumb.jpg

Share this post


Link to post
Share on other sites

This is how this implementation of hardware accelerated video output works:

  • Output bypasses X video driver by opening own disp layers. You can't use Xv from fbturbo at the same time, and on H3 the video is always on top and can't be overlapped by other windows.
  • OSD partly breaks X11 integration due to hardware limitations. The video area can't be overlapped by other windows. For fullscreen use this is no problem.

Only subtitles and OSD can overlap the video, but this works out of the box only on Xenial and requires recompilation of mpv on Jessie. But even controls will be displayed with OSD, mouse pointer will still not be visible, so you need to learn mpv shortcuts anyway.

Share this post


Link to post
Share on other sites

Someone on OrangePi facebook group said that he will try to port my code from OpenELEC which puts video layer in the background and normal layer in foreground. I guess that he didn't try that yet. Are you willing to do that?

Share this post


Link to post
Share on other sites

Someone on OrangePi facebook group said that he will try to port my code from OpenELEC which puts video layer in the background and normal layer in foreground. I guess that he didn't try that yet. Are you willing to do that?

I looked at the code, and seems like it's just a matter of setting correct settings here: https://github.com/linux-sunxi/libvdpau-sunxi/blob/master/sunxi_disp2.c#L56-L82

I'm not sure though how does this interact with desktop (i.e. fbturbo), and some values are not documented in current kernel sources.

Share this post


Link to post
Share on other sites

For example zorder is defined as

	unsigned char             zorder;      /*specifies the front-to-back ordering of the layers on the screen,
											 the top layer having the highest Z value
											 can't set zorder, but can get */

and in libvdpau-sunxi video layer has zorder 1 and OSD layer has zorder 2. So I guess that 0 is desktop layer, fbturbo doesn't seem to use disp2 layers for anything like drawing separate windows, so you can't really do anything here.

Share this post


Link to post
Share on other sites

Weird, I don't see the reason why that shouldn't be possible. In fact, I'm doing just that in my OpenELEC fork. Maybe someone on IRC will know the answer.

 

I also don't see any reason why would that affect fbturbo driver. Is there any special disp2 version? Which sources are used by Armbian?

Share this post


Link to post
Share on other sites

I'm saying that if you have whole desktop (including windows, menus, taskbar, etc) as a single layer with zorder 0 (can't say for sure that this is true, but it looks like it, maybe @ssvb can confirm or correct this), you can't really put anything behind separate desktop windows but in front of desktop background, at least without reordering layers and playing with transparency/alpha value.

Share this post


Link to post
Share on other sites

Yes, fb0 has zorder 0, but this is completely hidden to rendering SW, even fb driver is not aware of that. That means that you can freely reorder layers and set alpha values, which I did with a few lines of code. Only one question remains - what alpha value has non occupied part of the window. In my case, mali drivers always set it to completely transparent, so this principle works. Unfortunatelly, that also means that script.bin must be correctly set - framebuffer has to have alpha channel.

Share this post


Link to post
Share on other sites

Unfortunately this means that you need to calculate the shape of a "hole" for video, which means that you need to get coordinates and sizes for every X window (and preferrably of any "object" like tooltip or context menu)  and update it on window movement/resize/open/close events, so this has to be done in fbturbo or any other X output plugin if I understand this correctly.

Share this post


Link to post
Share on other sites

Highly depends how X11 rendering is done. I'm not willing to dig through all X11 code, so I guess I will just try it one time and see what happens.

Share this post


Link to post
Share on other sites

Someone on OrangePi facebook group said that he will try to port my code from OpenELEC which puts video layer in the background and normal layer in foreground. I guess that he didn't try that yet. Are you willing to do that?

 

I don't know enough about the XOrg to /dev/disp chain, but I'm willing to put my c coding skills to test! 

 

However, is there any hardware limitation which would make this not possible? My only query is trying to pump the resulting VPU generated bitmap to the X framebuffer (correct me if I have no idea what I'm talking about) would probably have an adverse performance hit.

Share this post


Link to post
Share on other sites

However, is there any hardware limitation which would make this not possible?

 

No, there is not. As I said, it's been done, albeit not with the same environment, if we've been talking about the subtitles, overlaping and other similar things.

 

 

My only query is trying to pump the resulting VPU generated bitmap to the X framebuffer (correct me if I have no idea what I'm talking about) would probably have an adverse performance hit.

 

Direct rendering could only help the performance and that is the thing someone usually desire, so it is already implemented in libvdpau-sunxi. Here we are talking about video layer Z (depth) order and if there is possibility to put playback layer below framebuffer and how that would be achieved without painful calculations of the visible window region.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
0