• Content count

  • Joined

  • Last visited

  1. @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 and give some more log to find your issue... rellla
  2. Set 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
  3. 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 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
  4. Dependencies from and the xorg package itself should help. Regards rellla
  5. 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
  6. 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.
  7. I have pushed the fix upstream. It should be available in armbian, when new libvdpau-sunxi packages are built. rellla
  8. 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
  9. dpkg -i “file“ as usual i think.
  10. Seems like it has to go somewhere ... Rellla
  11. You can try this deb file and see, if it works... It should include the above patch. rellla
  12. 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
  13. 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
  14. If it's really a libvdpau-sunxi issue, not.