jernej

Members
  • Content Count

    840
  • Joined

  • Last visited


Reputation Activity

  1. Like
    jernej got a reaction from manuti in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    @manuti No, I really didn't. Good to know.
  2. Like
    jernej reacted to manuti in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    Hi, your images @jernej are right here https://dl.armbian.com/_openelec/ I don't know if you know this or not.
    Regards
  3. Like
    jernej got a reaction from manuti in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    Hi!
     
    HW video decoding on mainline kernel is possible, but in most cases you have to do some kernel patching yourself and use special library which provides VAAPI or use modified ffmpeg libraries. MPEG2 decoding is possible with kernel 5.0 or 5.1 (not sure), basic H264 decoding will be possible with kernel 5.3 and HEVC decoding will probably come with kernel 5.5 (patches already exist). Note that H264 and HEVC codecs are feature incomplete currently. However, I did some improvements for LibreELEC and there most H264 and HEVC videos work. Patches are available on LibreELEC github but are incompatible with VAAPI library, so only option is to use modified ffmpeg.
     
    Regarding memory consumption, please note that with OrangePi Lite you have only 512 MiB of RAM which is a bit low. LibreELEC for that reason doesn't support devices with less than 1 GiB of RAM. Consider following calculations for memory requirements, no matter which kernel you use:
    1. Multiple variants of 4K and 1440p resolutions exist, so I'll assume that 4K means 4096x2160 (same as on my LG TV) and 1440p means 2560x1440
    2. kernel allocates one XRGB (4 bytes per pixel) buffer for user interface (no matter if you're using window manager or not), so for that you need 4096*2160*4 ~ 34 MiB of CMA memory
    3. video is decoded to NV12 or NV21 formats and both take 1.5 byte per pixel, that means 2560*1440*1.5 = 5.27 MiB of CMA memory per single frame
    4. worst case for H264 and HEVC is that you need 16 reference frames to properly decode current frame, which means additional 5.27 * 16 ~ 84 MiB of CMA memory
    5. VPU needs additional scratch buffers per frame. Size of those buffers depends on codec features used, but for H264 is typically about 1/4th of multiplied width and height, so in worst case (1 + 16)*2560*1440/4  ~ 15 MiB of CMA memory
    6. VPU needs some other scratch buffers, but they are small, about 1 MiB in total
    7. you also need additional CMA memory for providing encoded data to VPU, but memory consumption for that heavily depends on userspace library/player implementation. Hard to give any estimation, so let's use 20 MiB.
     
    Final estimation for worst case display + VPU CMA consumption for 4K display and 1440p video: 34 + 5.27 + 84 + 15 + 1 + 20 ~ 160 MiB. You also have to consider that other devices may use CMA memory at the same time. In LibreELEC, CMA memory size is set to 256 MiB because so much is needed for decoding 4K videos.
     
    Hopefully that gives you perspective how much memory is needed for H264/HEVC video decoding.
     
    I won't touch (use) 3.4 kernel anymore, but I can help you with patching mainline kernel for better H264 and/or HEVC support and bring up ffmpeg based solutions (that includes mpv), if you want.
  4. Like
    jernej got a reaction from manuti in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    In the old days, I provided OpenELEC images with 3.4 kernel (https://github.com/jernejsk/OpenELEC-OPi2) and it worked with 4K videos on 1080p display. Sadly, images don't exist anymore and source doesn't build anymore. Be aware, I used CedarX library instead of libvdpau-sunxi.
     
    I don't think I ever make it work with 4K screens, mostly because I didn't have such screen at the time.
  5. Like
    jernej got a reaction from genesys in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    Hi!
     
    HW video decoding on mainline kernel is possible, but in most cases you have to do some kernel patching yourself and use special library which provides VAAPI or use modified ffmpeg libraries. MPEG2 decoding is possible with kernel 5.0 or 5.1 (not sure), basic H264 decoding will be possible with kernel 5.3 and HEVC decoding will probably come with kernel 5.5 (patches already exist). Note that H264 and HEVC codecs are feature incomplete currently. However, I did some improvements for LibreELEC and there most H264 and HEVC videos work. Patches are available on LibreELEC github but are incompatible with VAAPI library, so only option is to use modified ffmpeg.
     
    Regarding memory consumption, please note that with OrangePi Lite you have only 512 MiB of RAM which is a bit low. LibreELEC for that reason doesn't support devices with less than 1 GiB of RAM. Consider following calculations for memory requirements, no matter which kernel you use:
    1. Multiple variants of 4K and 1440p resolutions exist, so I'll assume that 4K means 4096x2160 (same as on my LG TV) and 1440p means 2560x1440
    2. kernel allocates one XRGB (4 bytes per pixel) buffer for user interface (no matter if you're using window manager or not), so for that you need 4096*2160*4 ~ 34 MiB of CMA memory
    3. video is decoded to NV12 or NV21 formats and both take 1.5 byte per pixel, that means 2560*1440*1.5 = 5.27 MiB of CMA memory per single frame
    4. worst case for H264 and HEVC is that you need 16 reference frames to properly decode current frame, which means additional 5.27 * 16 ~ 84 MiB of CMA memory
    5. VPU needs additional scratch buffers per frame. Size of those buffers depends on codec features used, but for H264 is typically about 1/4th of multiplied width and height, so in worst case (1 + 16)*2560*1440/4  ~ 15 MiB of CMA memory
    6. VPU needs some other scratch buffers, but they are small, about 1 MiB in total
    7. you also need additional CMA memory for providing encoded data to VPU, but memory consumption for that heavily depends on userspace library/player implementation. Hard to give any estimation, so let's use 20 MiB.
     
    Final estimation for worst case display + VPU CMA consumption for 4K display and 1440p video: 34 + 5.27 + 84 + 15 + 1 + 20 ~ 160 MiB. You also have to consider that other devices may use CMA memory at the same time. In LibreELEC, CMA memory size is set to 256 MiB because so much is needed for decoding 4K videos.
     
    Hopefully that gives you perspective how much memory is needed for H264/HEVC video decoding.
     
    I won't touch (use) 3.4 kernel anymore, but I can help you with patching mainline kernel for better H264 and/or HEVC support and bring up ffmpeg based solutions (that includes mpv), if you want.
  6. Like
    jernej reacted to hexdump in Since Tanix TX6 can boot from the SD card   
    @jernej - good news: this patch seems to fix the emmc problem - on the eachlink i can now read and write the emmc in a stable way and on the qplus - where it was hanging on boot with emmc enabled in dtb - it does not hang anymore on boot and i can also read and write the emmc
  7. Like
    jernej got a reaction from drice in Hardware Graphic/Video Acceleration in H3 Mainline   
    It was not easy at all to come to this point. A lot of new code was written for ffmpeg, cedrus and Kodi to make it work. But since LibreELEC is closed ecosystem, we can afford to make some hacks which would otherwise cause issues with other programs.
     
    Anyway, I plan to rework some Cedrus patches these days to remove at least one hack and after that I can try to help you with using that special version of ffmpeg. Reportedly it works fine with unmodified mpv but I didn't test that yet. However, be prepared to pick a lot of patches from latest linux git master. Unfortunately, this is moving target and modified ffmpeg will work with only specific version of Cedrus driver.
     
    Once you are able to match ffmpeg and Cedrus driver it's best not to change anything until you have good reason to do so, like extending driver with new features.
  8. Like
    jernej reacted to hexdump in Since Tanix TX6 can boot from the SD card   
    @jernej - bisecting in progress - 14 rounds, so it will take a while
  9. Like
    jernej got a reaction from Jack953 in Kernel 5.2 new boards - Orangepi   
    Mali is only 3D accelerator, so I'm not sure what you mean exactly by that. If you mean HDMI output, that's entirely different thing, but it works. However, without any kind of acceleration.
     
    Mali T720 is not supported at all at this moment, however it will be soon.
  10. Like
    jernej got a reaction from chwe in Since Tanix TX6 can boot from the SD card   
    In case of Allwinner port of U-Boot, ATF (bl31.bin) gets packaged into itb file (u-boot.itb), along with U-Boot proper (u-boot.bin) and dtb file. You should just combine sunxi-spl.bin-arm32 (make sure is padded to 32K or 24K, I'm not sure ATM) and u-boot.itb.
     
    BTW, I'm not sure if mainline Linux works with BSP ATF binary. Just compile latest official ATF release (mainline H6 ATF is not board specific, so it should work).
     
    Not sure, I don't use earlyprintk. If it's not CPU mode issue (Linux expects that it's already in 64-bit mode) it may be DT issue.
     
    Anyway, I wouldn't bother with Linux at this stage. Fixing mainline DDR3 DRAM driver would help a lot with other issues.
  11. Like
    jernej got a reaction from Myy in The VPU driver   
    There is also VP9 decoding IP core , which is present in Allwinner H6, NXP i.MX8 and I think Rockchip has it too. It may be connected to Hantro and Google, but I'm unsure who is the original author.
  12. Like
    jernej got a reaction from Slackstick in Orangepi 3 h6 allwiner chip   
    @NicoD @johanvdw Actually with some of the out of tree patches is possible to make it work. After all, I have fully functional LibreELEC image for PineH64. Well, not completely everything, but HDMI audio works pretty well. Patches are here and here. Btw, dma patches are important for audio and you have to enable sun4i-i2s driver and simple audio card if it's not yet.
  13. Like
    jernej got a reaction from NicoD in Orangepi 3 h6 allwiner chip   
    @NicoD @johanvdw Actually with some of the out of tree patches is possible to make it work. After all, I have fully functional LibreELEC image for PineH64. Well, not completely everything, but HDMI audio works pretty well. Patches are here and here. Btw, dma patches are important for audio and you have to enable sun4i-i2s driver and simple audio card if it's not yet.
  14. Like
    jernej got a reaction from froezus in Beelink GS1 Allwinner H6   
    @froezus
    can you check if hdmi works after applying https://patchwork.kernel.org/patch/10882335/mbox/ ?
  15. Like
    jernej reacted to martinayotte in H6 Famous Reboot problem   
    I must have done something wrong, because after another trial, it works !!!
    So, I will investigate to figure out "what are the differences between those 2 u-boots", because I didn't found any yet ...
     
    EDIT : Bingo ! The missing thing is CONFIG_NR_DRAM_BANKS=1, although the documentation isn't explaining why, but it seems that diffs between OPis and PineH64 revealed this.
    I will do full image for OPiLite2 and OPiOnePlus and see if this issue is definitively gone ...
  16. Like
    jernej got a reaction from kexec in Orangepi 3 h6 allwiner chip   
    Issue is that U-Boot DT is missing ethernet0 alias. Solution is that you patch U-Boot, like I have done for PineH64 here.
  17. Like
    jernej got a reaction from Lin Xiaofeng in I2S interface on H6   
    Actually I already make it work on mainline: https://github.com/jernejsk/linux-1/commits/h6_i2s But I didn't sent patches yet, because DMA patches (pre-requirement) are still pending.
  18. Like
    jernej got a reaction from NicoD in Orangepi 3 h6 allwiner chip   
    It seems that OrangePi 3 has DDC_CEC_EN signal (pin PH2), which has to be enabled in order to read out EDID. Can someone try to enable it by hand and then re-plug hdmi to see if it helps?
     
    Correct solution would be to extend HDMI driver with additional DDC power supply or gpio property, like it's done here: https://github.com/Icenowy/linux/commits/h6-hdmi (IMO power supply is more appropriate solution).
  19. Like
    jernej got a reaction from lanefu in Orangepi 3 h6 allwiner chip   
    It seems that OrangePi 3 has DDC_CEC_EN signal (pin PH2), which has to be enabled in order to read out EDID. Can someone try to enable it by hand and then re-plug hdmi to see if it helps?
     
    Correct solution would be to extend HDMI driver with additional DDC power supply or gpio property, like it's done here: https://github.com/Icenowy/linux/commits/h6-hdmi (IMO power supply is more appropriate solution).
  20. Like
    jernej got a reaction from gounthar in Orangepi 3 h6 allwiner chip   
    It seems that OrangePi 3 has DDC_CEC_EN signal (pin PH2), which has to be enabled in order to read out EDID. Can someone try to enable it by hand and then re-plug hdmi to see if it helps?
     
    Correct solution would be to extend HDMI driver with additional DDC power supply or gpio property, like it's done here: https://github.com/Icenowy/linux/commits/h6-hdmi (IMO power supply is more appropriate solution).
  21. Like
    jernej got a reaction from @lex in Orangepi 3 h6 allwiner chip   
    DMA channels for SPI0 are 22 and 22 (Rx, Tx).
     
    BTW, I already sent patches, but I still want to know if it will work for you once you fix DT issues.
  22. Like
    jernej got a reaction from guidol in Orangepi 3 h6 allwiner chip   
    It would be weird if you wouldn't get this error. This actually tells you that U-Boot checked if environment variables are stored somewhere. It looked at configured place, noticed that CRC doesn't match and concluded that it will use default environment instead.
     
    In short, this error is normal and it would go away only if you would execute "saveenv" command in U-Boot.
  23. Like
    jernej got a reaction from manuti in Orange Pi One Plus Desktop Enviroment   
    I have H6 DRM patches prepared for 4.20, so you can just copy them over. However, I think you would need some more of them for 4.19. Currently, we're investigating some troubles with HDMI, so it's not stable yet anyway.
  24. Like
    jernej got a reaction from TimSmall in Kickstarter: Allwinner VPU support in the official Linux kernel   
    I'll try to add support for it soon. But it will be in the same boat as others at first. Don't expect to have 10 bit HEVC support at the beginning. BTW, VP9 is separate peripheral so it needs separate driver. Since nobody did reverse engineering yet, it will take a long time to be supported. However, it seems to be Webm project reference VP9 HW decoder, so there is a great chance that other SoCs from other manufacturers have same unit and someone else might write a driver for it.
  25. Like
    jernej got a reaction from TonyMac32 in Kickstarter: Allwinner VPU support in the official Linux kernel   
    I'll try to add support for it soon. But it will be in the same boat as others at first. Don't expect to have 10 bit HEVC support at the beginning. BTW, VP9 is separate peripheral so it needs separate driver. Since nobody did reverse engineering yet, it will take a long time to be supported. However, it seems to be Webm project reference VP9 HW decoder, so there is a great chance that other SoCs from other manufacturers have same unit and someone else might write a driver for it.