AnonymousPi Posted October 19, 2016 Posted October 19, 2016 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.
zador.blood.stained Posted October 19, 2016 Posted October 19, 2016 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.
jernej Posted October 20, 2016 Posted October 20, 2016 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?
zador.blood.stained Posted October 20, 2016 Posted October 20, 2016 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.
jernej Posted October 20, 2016 Posted October 20, 2016 Yes, these few lines should be added at open: https://github.com/jernejsk/OpenELEC-OPi2/blob/openelec-7.0/projects/H3/patches/kodi/kodi-005-H3-support.patch#L680-L694and those at close: https://github.com/jernejsk/OpenELEC-OPi2/blob/openelec-7.0/projects/H3/patches/kodi/kodi-005-H3-support.patch#L680-L694 Which values have you in mind? I guess best way to discover if it works is to test it.
zador.blood.stained Posted October 20, 2016 Posted October 20, 2016 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.
jernej Posted October 20, 2016 Posted October 20, 2016 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?
zador.blood.stained Posted October 20, 2016 Posted October 20, 2016 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.
jernej Posted October 20, 2016 Posted October 20, 2016 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.
zador.blood.stained Posted October 20, 2016 Posted October 20, 2016 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.
jernej Posted October 20, 2016 Posted October 20, 2016 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.
AnonymousPi Posted October 20, 2016 Author Posted October 20, 2016 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.
jernej Posted October 22, 2016 Posted October 22, 2016 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.
Recommended Posts