rellla

Members
  • Content Count

    88
  • Joined

  • Last visited


Reputation Activity

  1. Like
    rellla got a reaction from tkaiser in orangepi Mali HW acceleration in setenv   
    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.
  2. Like
    rellla got a reaction from tkaiser in Orange Pi PC newer MPV versions?   
    I have pushed the fix upstream. It should be available in armbian, when new libvdpau-sunxi packages are built.
     
    rellla
  3. Like
    rellla got a reaction from zador.blood.stained in Orange Pi PC newer MPV versions?   
    I have pushed the fix upstream. It should be available in armbian, when new libvdpau-sunxi packages are built.
     
    rellla
  4. Like
    rellla got a reaction from RagnerBG in Orange Pi PC newer MPV versions?   
    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
  5. Like
    rellla got a reaction from Igor in Custom Kernel   
    Thanks guys, this was exactly what i need.
    rellla
  6. Like
    rellla got a reaction from zador.blood.stained in armbian 5.10 to 5.11 break video playback (cb2)   
    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.
  7. Like
    rellla got a reaction from zador.blood.stained in armbian 5.10 to 5.11 break video playback (cb2)   
    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
  8. Like
    rellla got a reaction from Avi in armbian 5.10 to 5.11 break video playback (cb2)   
    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
  9. Like
    rellla got a reaction from tkaiser in armbian 5.10 to 5.11 break video playback (cb2)   
    Yes. And there it is. Something (the app-> mpv) is setting the values...
    Standard (without setting anything) for bright/contrast/sat/hue is 0.00/1.00/1.00/0.00 which is done initially in vdpau.
    After that MPV sets this to 0.068/1.000/0.479/-0.068 which results on the values 53/50/24/49, which go to the display driver.
    The problematic value is the 0.479 saturation value, which is just half of it should be...
     
    Find out, if you can adjust this in MPV or why MPV uses this settings. I think, this is the issue.
  10. Like
    rellla reacted to hatahata in no sound on vlc of prange pi PC   
    hi all .
     
    i nstall both minidlna and vlc .
     
    i hear sound youtube from HDMI (iceweasel).
     
    but
    by vlc on armbian i can not hear normal sound from HDMI , only rarely get noise from HDMI .
    (i  try audio  -> audio device , but no effect)
     
    what should i do ?
     
     
     

  11. Like
    rellla reacted to jernej in Orange pi plus 2e   
    What do you mean by that? UI happily works with sunxi mali drivers. Did you mean VDPAU gles extensions? In that case my opinion is that Mali GPU is too slow for 4K cropping/scaling/rendering and Display engine (video unit) is much more convenient and capable for this.
     
     
     
    SD card and eMMC installation are completely the same in functionality. Install script copies over same U-Boot, same script.bin, same kernel and same filesystem. In fact eMMC is often seen as SD card on chip (a bit simplified).
  12. Like
    rellla got a reaction from zador.blood.stained in Orange pi plus 2e   
    OSD is available via software (pixman) on socs without G2D.The problem with Kodi is, that there is currently no prebuilt alternative to jernej ones. But this one uses Allwinner's code ... (<- as discussed on various other places).
    Mosterta has done and is still trying (AFAIK) to do an implementation with using linux-sunxi.org/cedrus , the reverse engineered code from linux-sunxi community. More info about kodi story here: linux-sunxi.org/kodi (<- to be continued)
    UI in kodi works through gles though which has to be implemented via Mali on sunxi. On both forks.
    Rellla
  13. Like
    rellla reacted to zador.blood.stained in Orange pi plus 2e   
    I would guess no UI overlays (on video) and no subtitles (especially on H3 which doesn't have G2D)?
  14. Like
    rellla got a reaction from zador.blood.stained in black screen mpv player   
    1) use https://github.com/rellla/softhddevice-openglosd/tree/glesas source for the softhddevice plugin
    2) compile it with "GLES2=1 make"
    Glut is needed for the opengl version. We are on arm, we don't have that.
    And be aware: it's WIP!
    Didn't I say that already ?
  15. Like
    rellla got a reaction from tkaiser in black screen mpv player   
    If CONFIG_CMA is not set, you have to set sunxi_ve_mem_reserve. 150+ would be a good value. In Armbian default it is not set.
    If CONFIG_CMA is set, sunxi_ve_mem_reserve= is ignored. By default, the CMA memory is hardcoded to 80MB.
     
    So, if no patch activates CMA, you don't have to care about that, but just set sunxi_ve_mem_reserve. In this case, you also don't need libump and must not compile libcedrus with USE_UMP=1.
    To let Mali and the VE use the same memory area for zerocopy features in the future (for the upcoming vdpau_gles_interop feature e.g.) you need to use UMP with CMA memory as backend. And then you have to increase the hardcoded 80MB depending on how much surfaces etc. your app uses.
     
    I hope, this was kind of understandable
     
    Regards
    rellla
  16. Like
    rellla got a reaction from zador.blood.stained in black screen mpv player   
    If CONFIG_CMA is not set, you have to set sunxi_ve_mem_reserve. 150+ would be a good value. In Armbian default it is not set.
    If CONFIG_CMA is set, sunxi_ve_mem_reserve= is ignored. By default, the CMA memory is hardcoded to 80MB.
     
    So, if no patch activates CMA, you don't have to care about that, but just set sunxi_ve_mem_reserve. In this case, you also don't need libump and must not compile libcedrus with USE_UMP=1.
    To let Mali and the VE use the same memory area for zerocopy features in the future (for the upcoming vdpau_gles_interop feature e.g.) you need to use UMP with CMA memory as backend. And then you have to increase the hardcoded 80MB depending on how much surfaces etc. your app uses.
     
    I hope, this was kind of understandable
     
    Regards
    rellla
  17. Like
    rellla got a reaction from dimag0g in OpenGL on Mali GPU (BananaPi, OrangePi PC, etc)   
    https://github.com/ptitSeb/glshim is a wrapper to execute OpenGL1.x (<-desktop!) code embedded systems which only provide OpenGL/ES 1.1
    The only thing that differs from the desktop image should be the last point. Installation of glshim. If that would be necessary in a desktop distribution? I would prefer to get that optionally if ever. Though it's a nice gimmick imho.
    Trying to get GL working on GL/ES platform is hacky anyway. At least when dealing with the minor version numbers glshim supports.
     
    Regards
    rellla
  18. Like
    rellla reacted to rellla in H3 kernel repo   
    RagnerBG: the pixman issue should be worked around with the last commit in my dev tree. There is/was some minor issue, that should be easy to fix. I still have to look into it.... Kodi does the gui with gles afaik. Not with cpu via pixman.
     
    jernej: do you stay in contact with mosterta regarding libvdpau-sunxi and kodi? Maybe we should all come together in #cedrus some time ...
    What is the license / eula of the linked mali libs? I did not follow the link so far ...
     
    Regards
    rellla
  19. Like
    rellla got a reaction from Igor in Kodi/XBMC on Armbian with HW Accleration possible?   
    Hi all,

    I have been reading through this thread and it makes me kind of sad...
     
    This software called CedarX is known to violate the GPL. Please do not do any things with this but i ask everyone to work with http://linux-sunxi.org/Cedrus, the libre open source reverse engineered counterpart.
     
    Based on Allwinner software? GPL?
     
    Sure it won't work with the effort of a few hours because this is WIP software, hacked around developer boards. And it's not a matter of Armbian, because Armbian is just Debian and you can do everything you do can with Debian, too.
     
    Good to know that you don't want to use this because iirc this is using Allwinner code, probably GPL violating. People always want quick solutions. And this is the main problem. They even don't care of using GPL violating software.
    If interest in open source software -> http://linux-sunxi.org/Cedrus would be more present, we could have had a more mainlined kernel driver for the video engine already. And maybe Team-Kodi would have recognized this effort, too. But only talking about "CedarX", the GPL violating Allwinner code, slows that effort down dramatically.
     
    With the right bits of software, it will for sure run on linux. There are just too few people working on a suitable, long-term, solution using open source software.
    New Mali drivers are not needed.
    What is the good reason, why Team-Kodi has no intention?
    I advise everyone, that has the skills, to work on mosterta's solution, working with GPL violation software is not the right way.
    There are still efforts to make Kodi available on Allwinner with open source software. This simply needs time. See mosterta's post as a personal memo. Though some bits are missing there, which can be found all over the net somewhere.

    Regards
    rellla
  20. Like
    rellla got a reaction from tkaiser in Kodi/XBMC on Armbian with HW Accleration possible?   
    Hi all,

    I have been reading through this thread and it makes me kind of sad...
     
    This software called CedarX is known to violate the GPL. Please do not do any things with this but i ask everyone to work with http://linux-sunxi.org/Cedrus, the libre open source reverse engineered counterpart.
     
    Based on Allwinner software? GPL?
     
    Sure it won't work with the effort of a few hours because this is WIP software, hacked around developer boards. And it's not a matter of Armbian, because Armbian is just Debian and you can do everything you do can with Debian, too.
     
    Good to know that you don't want to use this because iirc this is using Allwinner code, probably GPL violating. People always want quick solutions. And this is the main problem. They even don't care of using GPL violating software.
    If interest in open source software -> http://linux-sunxi.org/Cedrus would be more present, we could have had a more mainlined kernel driver for the video engine already. And maybe Team-Kodi would have recognized this effort, too. But only talking about "CedarX", the GPL violating Allwinner code, slows that effort down dramatically.
     
    With the right bits of software, it will for sure run on linux. There are just too few people working on a suitable, long-term, solution using open source software.
    New Mali drivers are not needed.
    What is the good reason, why Team-Kodi has no intention?
    I advise everyone, that has the skills, to work on mosterta's solution, working with GPL violation software is not the right way.
    There are still efforts to make Kodi available on Allwinner with open source software. This simply needs time. See mosterta's post as a personal memo. Though some bits are missing there, which can be found all over the net somewhere.

    Regards
    rellla