rellla

Did you try mpv --vo=vdpau --hwdec=vdpau --hwdec-codecs=all according to http://linux-sunxi.org/Cedrus/libvdpau-sunxi? Regards

@RagnerBG: Totally right. VDPAU is an API for decoding and presentation. It's used by several players. Encoding is not included in this API. "Cedrus" is the project name of the reverse engineering effort in general. libvdpau-sunxi is based on cedrus code. ffmpeg-cedrus is based on cedrus code. As i can see in the readme, ffmpeg-cedrus only does hardware accelerated encoding. I have no clue, how the libvdpau-sunxi backend works together with ffmpeg in case of decoding with --hwaccel vdpau option - but imho it should work with some adaptions. You may check https://github.com/linux-sunxi/libvdpau-sunxi/issues/55 and give some more log to find your issue... rellla

Set https://github.com/igorpecovnik/lib/blob/master/compile.sh#L16 and the next line to yes, and your build system will give you deb packages, you can easily install on your system via dpkg -i *.deb You will also be able to change the kernel config then. Regards rellla

The kernel module is not loaded, because noone assignes memory to the device, because the boot parameter sunxi_ve_mem_reserve is set to 0 and the kernel does not support CMA. 1. Either build the kernel with CMA enabled and set to e.g.128MB or enable sunxi_ve_mem_reserve in boot.cmd https://github.com/igorpecovnik/lib/blob/master/config/bootscripts/boot-sunxi.cmd#L40 I don't know, how you can easily set this with build tools. 2. If you build your image yourself, you can add userpatches and/or do a kernel config during build process, where you can enable CMA. Regards rellla

Dependencies from https://packages.debian.org/de/jessie/libvdpau-dev https://packages.debian.org/de/jessie/libvdpau1 and the xorg package itself should help. Regards rellla

Hardware acceleration works with legacy kernel via libvdpau-sunxi. And this depends on X11. You do not need a complete desktop/window manager environment, just X. There are other ways to use cedrus code directly without VDPAU API to decode/encode sth. Code snippets should lay somewhere around the net, but i don't really know more about them. Regards rellla

libvdpau-sunxi accelerates OSD/rgba surfaces composing if the application uses vdpau API. libvdpau-sunxi does not speak with xf86-video-fbturbo when it comes to compose windows etc. on screen, as it directly interacts with the hardware/display engine. xf86-video-turbo accelerates 2D operations like window moving and scrolling. Nothing else. It has nothing to do with OSD of vdpau. Regards rellla @peter12: I don't see any issue with libvdpau-sunxi itself in your log. It's loading fine. I suppose the input format is incompatible and not supported by libvdpau-sunxi, so it falls back to software solution.

I have pushed the fix upstream. It should be available in armbian, when new libvdpau-sunxi packages are built. rellla

PowerVR should be mentioned, although it's not that relevant. 2D acceleration in the context of G2D or "Mixer Processor" means, that there exists a dedicated IP core in the hardware, that is optimized to do the following (raster graphics) mem2mem operations (listed in usermanual, page 320): On the newer SoCs we don't have this piece of hardware and have to do that in software. Therefore, libvdpau-sunxi uses pixman to do this operations (e.g. on H3), which calls the best possible software acceleration (e.g. NEON) to do these operations. Regards rellla @peter12: My post was only a reply to tkaiser. Not really related to your problem

dpkg -i “file“ as usual i think.

http://linux-sunxi.org/User:Rellla/Video_and_graphics_acceleration Seems like it has to go somewhere ... Rellla

You can try this deb file and see, if it works... It should include the above patch. rellla

This code snippet checks, if the last osd frame has to be cleared before blitting a new one into it, in case it has not been cleared before. If we need the clear, it now uses the PIXMAN_OP_SRC operator, which indicates, that pixman would delete the old part. PIXMAN_OP_OVER just does alpha blending and does not delete the existing OSD. The operators are equal to CAIRO_OPERATOR_SOURCE and CAIRO_OPERATOR_OVER here. You can either build libvdpau-sunxi yourself with this patch, or ask someone to build a .deb, that you can easily test. If i find some time, i'll try to provide such a debian package. Regards rellla

It should be this part, which should be sth. like this int operation_type = (rgba_dst->flags & RGBA_FLAG_NEEDS_CLEAR) ? PIXMAN_OP_SRC : PIXMAN_OP_OVER; pixman_image_composite32( operation_type, src, NULL, dst, (src_rect->x0 * fscale_x), (src_rect->y0 * fscale_y), 0, 0, dst_rect->x0, dst_rect->y0, (dst_rect->x1 - dst_rect->x0), (dst_rect->y1 - dst_rect->y0)); Not tested though Regards rellla

If it's really a libvdpau-sunxi issue, not.

I suppose this is no mpv issue but a libvdpau-sunxi issue. Imho it's a bug within osd handling and has to be fixed there. Maybe i'll find some time to look at it. Everyone else is welcome, too for sure. Rellla

Oh. Very customizable Thanks! rellla

One additional thing though: Maybe https://github.com/igorpecovnik/lib/blob/master/configuration.sh#L76should be moved to line 106 or 186 in order to be able to also set $LINUXCONFIG ?! rellla

Thanks guys, this was exactly what i need. rellla

Hello all, maybe I missed that part in the docs or in another thread... In fact, I haven't found a solution. I'd like to include a custom kernel repository in the build process (maybe in kernel-only mode) and select that in the interface if available. Either include a remote directory (github...) or some local directory. That all for easily trying things out without using the single-patches directory but using the armbian building environment. I couldn't find the lines in the build scripts, where I easily can "hardcode" such a kernel tree. Ultimate way would be an additional option for a custom kernel tree, chooseable via the menu. Can someone point me into the right direction? Thanks rellla

I think i found the problem: The vdpau in-built color space conversion uses a YCbCr->RGB conversion matrix depending on the Color Space (BT601 ...) as the base. This matrix can be processed with procamp values, that creates the new csc matrix. We cannot push that matrix directly into the sunxi display engine, but only the single values. So we have to calculate backwards using the resulting matrix (incl. procamp) and the original one. And here comes the issue... MPV uses his own base matrix, processes it themselves with some procamp values and gives it to vdpau. To calculate backwards, we need the base matrix, which is currently unknown within vdpau. And sadly it's different from ours, because it uses one for YUV->RGB conversion. What now seems to happen is the following: MPV creates a csc-matrix (YUV->RGB), vdpau calculates backwards using the standard BT.601 matrix (YCbCr->RGB) and gets single values, that are not intended to be set by mpv... The only thing we can do is, either to live with this issue or find a workaround to indicate, when the YUV->RGB matrix values have to be used for the backwards calculation. Doing that should not be the most ugly hack and should of course not break the rest. Any hints are welcome Reference: http://www.equasys.de/colorconversion.html rellla

Yeah, i talked with MPV people in irc in the meantime and concluded the same. Either the backwards calculation has some bug, the matrix is wrong or we miss some other bit... I have to check the first one with doing some tests with https://github.com/rellla/snippets/tree/master/sunxi_csc I'd like to see, that the calculation is right. But first we have to look into the matrices itself. Maybe I'll add a function in vdpau code to print them and see what's different ... Kind of strange that whole CSC thing... Edit: The function you linked should be definitely the one we have to compare with vdpau calculation routines.

Thanks for testing. I'll have to look into mpv code. And no, it should not break anything on H3, because display2.0 is not using the equalizer... EDIT: Looking into mpv player code, it seems, that they don't scale their contrast and saturation value from 0.00-1.00-10.00 like vdpau spec likes it to have, but only map their -100~+100 to 0.00~1.00 So default is 0, which gets 0.50 in vdpau. According to ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/struct_vdp_procamp.html#a96fd21f127e9b5ba24024f60ae42851dthis is wrong because it should be 1.00 Conclusion: Imho no libvdpau-sunxi issue but sth. mpv related

I will look into that anyway, because a +100 sat value in MPV should get an 10.00 value in vdpau which should result in the maximum (100) for the display driver. Therefore, 0 in MPV should mean "no change" (1.00) in vdpau and 50 in display. Hm. Maybe you can adjust all the values in realtime (with number keys iirc) and see what is going on in the logs... Anyway, glad to here we got it working