jernej

  • Posts

    1033
  • Joined

  • Last visited

Reputation Activity

  1. Like
    jernej got a reaction from Willy Moto in Allwinner H6   
    Starting 5.12, no kernel patches are needed for H264. With 5.14 (due in about a week or two), only HEVC needs patches. Other supported codecs (MPEG2, VP8, H264) do not.
     
    You still have to make sure that you have enough CMA memory available. 4k videos can be pretty demanding in worst case. I would suggest 256 MiB just to be on the safe side.
  2. Like
    jernej got a reaction from gounthar in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    Which is your kernel version?
     
    This is 4.3.1 branch which should work with kernel 5.13: https://github.com/jernejsk/FFmpeg/commits/v4l2-request-hwaccel-4.3.1-new
     
    gstreamer also made a ton of progress in last few days and it currently passes even more H264 conformance tests than ffmpeg. However, you need to build latest source from git.
  3. Like
    jernej got a reaction from lanefu in Allwinner H6   
    Starting 5.12, no kernel patches are needed for H264. With 5.14 (due in about a week or two), only HEVC needs patches. Other supported codecs (MPEG2, VP8, H264) do not.
     
    You still have to make sure that you have enough CMA memory available. 4k videos can be pretty demanding in worst case. I would suggest 256 MiB just to be on the safe side.
  4. Like
    jernej got a reaction from Werner in Allwinner H6   
    Starting 5.12, no kernel patches are needed for H264. With 5.14 (due in about a week or two), only HEVC needs patches. Other supported codecs (MPEG2, VP8, H264) do not.
     
    You still have to make sure that you have enough CMA memory available. 4k videos can be pretty demanding in worst case. I would suggest 256 MiB just to be on the safe side.
  5. Like
    jernej got a reaction from Dan MacDonald in Allwinner H6   
    Starting 5.12, no kernel patches are needed for H264. With 5.14 (due in about a week or two), only HEVC needs patches. Other supported codecs (MPEG2, VP8, H264) do not.
     
    You still have to make sure that you have enough CMA memory available. 4k videos can be pretty demanding in worst case. I would suggest 256 MiB just to be on the safe side.
  6. Like
    jernej got a reaction from jock in Mainline VPU   
    Yeah, LE currently uses 5.10 kernel because we are preparing stable release (no ETA, but hopefully soon). Only after that Linux will be updated to whatever current stable release will be at the time. However, v4l2 request api ffmpeg patches for Linux 5.13 can be found here. Note that they are untested and you still need corresponding kernel patches too.
  7. Like
    jernej got a reaction from rubenvb in Mainline VPU   
    Pick patches 14-23 here: https://github.com/jernejsk/LibreELEC.tv/tree/linux-5.13/projects/Allwinner/patches/linux
     
    With that, HEVC should work without problem. Official HEVC API still needs some work.
     
    Not a problem, I usually update them with every stable kernel release, just to check on progress.
  8. Like
    jernej got a reaction from rubenvb in Mainline VPU   
    Yeah, LE currently uses 5.10 kernel because we are preparing stable release (no ETA, but hopefully soon). Only after that Linux will be updated to whatever current stable release will be at the time. However, v4l2 request api ffmpeg patches for Linux 5.13 can be found here. Note that they are untested and you still need corresponding kernel patches too.
  9. Like
    jernej got a reaction from Werner in Allwinner sun8i creates trace when scaning for WiFi   
    Here is early work for proper XR819 mainline support. Tests reports are welcome, to see if it is actually any better than vendor driver. I got reasonable speed using it and only problem I can see is that suspend doesn't work. Of course, developer tests rarely last more than a few minutes, so long term stability isn't known.
     
    Note, I extracted pretty recent FW binaries from H616 Android box, which should be better than old ones, in theory.
  10. Like
    jernej got a reaction from Werner in Orange PI Lite2 no more 1920x1080 - kernel 5.5.x   
    I found the culprit. Patch https://github.com/armbian/build/blob/master/patch/kernel/archive/sunxi-5.13/board-h6-orangepi-lite2-fix-missing-all.patch messes up HDMI node, which then doesn't properly enable DDC lines and then in turn, HDMI driver can't read EDID.
     
    @Igor any reason for above patch to be so big? OPi Lite2 is pretty well supported in 5.13. Only nodes which are not present in mainline are spi0, usb3phy and dwc3. Patch can be much smaller...
  11. Like
    jernej got a reaction from gounthar in Orange Pi Zero (H2+/H3) TV Out on Mainline, WORKING   
    @Cesar Berci it got me interested enough that I ported changes to v5.10 with cleaner approach. Here you have commit: https://github.com/jernejsk/linux-1/commit/ad153ef6ee5be33531187f97d5fa0c07455dc795
    NOTE: You have to enable tve node in DT you want. I did that in OPi PC.
  12. Like
    jernej got a reaction from JORGETECH in Orange Pi Zero (H2+/H3) TV Out on Mainline, WORKING   
    @Cesar Berci it got me interested enough that I ported changes to v5.10 with cleaner approach. Here you have commit: https://github.com/jernejsk/linux-1/commit/ad153ef6ee5be33531187f97d5fa0c07455dc795
    NOTE: You have to enable tve node in DT you want. I did that in OPi PC.
  13. Like
    jernej got a reaction from balbes150 in Help me TX6 detect 3GB RAM   
    Check U-Boot output on serial. It should say something like 4 GiB of RAM detected, 3 GiB used. That won't change, since it's impossible to use that extra GiB due to HW limitations.
  14. Like
    jernej got a reaction from MX_Master in How to switch H6's ARISC (CPUS) core clock source? :)   
    If I'm not mistaken, yes. You can always make a SPL hack, which do stuff with otherwise protected resources.
  15. Like
    jernej got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    @XFer012Check USB changes here https://github.com/jernejsk/linux-1/commit/a57b81d6188b0f8888d4856c17eff5c5e9816fd8 You can ignore others. Note the changes in number of phys in usbphy nodes.
  16. Like
    jernej got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    @XFer012Above DT change will most probably lock up CPU - CPU is changing clock from which it is running. Much safer bet is to change CONFIG_SYS_CLK_FREQ in U-Boot to the frequency you want. There CPU is first switched to alternate (slow) clock source and once main CPU clock is adjusted, it's switched back.
  17. Like
    jernej got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    You can try with (but no guarantee) in cpu0 node:
    assigned-clocks = <&ccu CLK_CPUX>; assigned-clock-rates = <1080000000>; Safe default is set in SPL (one of the first things that's is done).
    Note that everything is done by community without any plan. I just told you current pattern regarding these things. It could be that someone would prepare such patches soon or no one would find it interesting enough to work on it.
  18. Like
    jernej got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    Check ohci, ehci and usbphy nodes in my DT: https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts#L134 and https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi. You should make a patch which adds these changes to DT, add patch to build system and build image. You can probably get away with making DT overlay too.
    Note that these are developer level instructions - I don't plan to write more detailed steps.
  19. Like
    jernej got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    that gets sorted out usually very late, when a lot of other features are already working.
     
    Those messages don't indicate alpha stage. Disabling just means that regulator was enabled at boot but Linux doesn't need it. "using dummy regulator" means that voltage regulator is not needed (vcc- regulators might get specified later but most of the time are not needed). syscon value message is imo useless and will probably get removed sooner or later.
    In short - several of these messages will probably stay in later, more complete kernel.
  20. Like
    jernej got a reaction from Werner in OrangePi Zero2 - Allwinner H616   
    It's possible to make it work if you enable all USB nodes in DT. It seems like some HW quirk.
  21. Like
    jernej got a reaction from P.P.A. in Understanding Hardware-Accelerated Video Decoding   
    This happens on all SoCs with DE2 or newer (A83t or newer SoC). Most SoCs have only one capable plane which can display YUV formats and it's always below current framebuffer, so that "workaround" (which imo is not workaround, but just part of configuration) is always needed in your use case. Note that having video plane below UI plane is actually desired for video players - UI plane has alpha channel which makes window with video transparent.
  22. Like
    jernej got a reaction from gounthar in Understanding Hardware-Accelerated Video Decoding   
    Good summary, let me clear some things.
    Having proper uAPI by no means makes libva-v4l2-request obsolete. If this lib is updated to latest uAPI, it still could serve as intermediate layer for all apps that don't support new interface but they support VA-API.
    Before you talked about libva-v4l2-request, which implements VA-API, so I wouldn't say it's irrelevant to ARM HW accel. libvdpau-sunxi implements VDPAU, but that works only on BSP kernels and it is not relevant for mainline.
    Further clarification: Kodi 19.0 (released recently) is highly recommended for all this - it doesn't require any out of tree patch for video decoding (LE uses patch for HW deinterlacing). Additionally, with version 19.0, there is single binary for all 3 windowing systems (gbm, X11, wayland). Depends on build options. Not sure if this version is available on Armbian but PPA exists, so I guess it should not be hard to test.
    H264, MPEG2 and VP8 should be good in mainline, although api can still change until codec is promoted to uAPI. HEVC still needs out-of-tree patches for any serious work.
     
    Maybe you can update your text, so we have current state overview in single post.
     
  23. Like
    jernej got a reaction from P.P.A. in Understanding Hardware-Accelerated Video Decoding   
    Good summary, let me clear some things.
    Having proper uAPI by no means makes libva-v4l2-request obsolete. If this lib is updated to latest uAPI, it still could serve as intermediate layer for all apps that don't support new interface but they support VA-API.
    Before you talked about libva-v4l2-request, which implements VA-API, so I wouldn't say it's irrelevant to ARM HW accel. libvdpau-sunxi implements VDPAU, but that works only on BSP kernels and it is not relevant for mainline.
    Further clarification: Kodi 19.0 (released recently) is highly recommended for all this - it doesn't require any out of tree patch for video decoding (LE uses patch for HW deinterlacing). Additionally, with version 19.0, there is single binary for all 3 windowing systems (gbm, X11, wayland). Depends on build options. Not sure if this version is available on Armbian but PPA exists, so I guess it should not be hard to test.
    H264, MPEG2 and VP8 should be good in mainline, although api can still change until codec is promoted to uAPI. HEVC still needs out-of-tree patches for any serious work.
     
    Maybe you can update your text, so we have current state overview in single post.
     
  24. Like
    jernej got a reaction from hexdump in OrangePi Zero2 - Allwinner H616   
    If someone has too much time, here is extremely basic and hackish H616 display driver (HDMI up to 1080p only): https://github.com/jernejsk/linux-1/tree/h616-hdmi (take branch as-is, USB works too)
  25. Like
    jernej got a reaction from guybrushthreepwood in [SOLVED] Orange Pi PC H3 Armbian Focal 5.10.4-sunxi av tv out cvbs enable   
    Yes, meson uses stateful whereas Cedrus and rkvdec use stateless (request api).
    Actually only one really worked on this driver but stopped working on most (all?) things due to real-life issues.
    Vanilla Kodi will work for video decoding, but if you want HW deinterlacing, that will need Kodi patch and additional one for ffmpeg.