jernej

  • Posts

    1045
  • Joined

  • Last visited

5 Followers

Recent Profile Visitors

7389 profile views

jernej's Achievements

  1. jernej

    Mainline VPU

    @usual userno idea then. Best to wait on RK devs to update patches, but that will take some time... @iamdrqIt looks you're using 10-bit video sample. It's always good idea to try 8-bit first.
  2. jernej

    Mainline VPU

    Ah, yes, that should work with upstream VP9 API. I'm not sure what could broke with kernel update. There are few HEVC patches that were upstreamed. Maybe order of the fields changed? You can try simple experiment. Copy hevc-ctrl.h from patched kernel sources to ffmpeg sources (replace existing file) and rebuild ffmpeg. If it fails to build, you know some, probably minor, updates are needed. If it goes through, it might just work.
  3. jernej

    Mainline VPU

    Note that final VP9 API, which landed in media repo, is slightly different than before and new ffmpeg patches will be needed. We only have WIP variant for new VP9 API. It works, but breaks SW VP9 decoding. We have some time untill it lands in stable kernel...
  4. If you want video decoding acceleration to work on Kodi with Allwinner SoCs, you need gbm version of Kodi (e.g. without desktop running) and patched version of ffmpeg (I don't think that's provided on Armbian).
  5. Did anyone actually bother to port AW859A driver to mainline? I certainly didn't.
  6. jernej

    Mainline VPU

    I don't use any desktop environment (X11 or Wayland) on SBCs, so I can't tell you what works and what not. However, I can tell you that v4l2 request drivers decode video frames to dma-buf, which can be directly imported into DRM or OpenGL ES (mesa exposes functions to do that, but afaik it convert colour space with GPU, still much quicker than CPU). Later option should work everywhere where OpenGL ES is supported, so under X11 and Wayland too. At first glance, it seems that mpv doesn't have this implemented, but I'm not sure. Kodi has both rendering methods implemented, but only when using GBM variant (nobody bothered to enabled that for other environments).
  7. Sorry, I don't know. I don't use X11 nor displays via SPI.
  8. FYI, if anyone is interested in advancing Armbian support for H616, I just fixed reboot issue on mainline kernel for OrangePi Zero2. In fact, I started collecting H616 patches in hope to create LibreELEC image. Patches can be found here: https://github.com/jernejsk/linux-1/commits/h616-full Note: U-Boot needs this hack: https://github.com/jernejsk/u-boot/commit/d420184997f302f546bb0862b1774cca6b43fb9a Without it, Linux will hang at loading Panfrost driver.
  9. sorry, I'm occupied with other work.
  10. of course, unless you really know what you're doing, it's much easier to create patch for kernel (where DT resides) and build Armbian image with it.
  11. Yes, TX6 uses DDR3, whereas OPi3 uses LPDDR3 IIRC. Is there TX6 support? If so, you just need to copy ethernet part in DT.
  12. Not easy. You would need some kernel patches and enabled additional drivers. As far as I can see there is no H6 board supported by Armbian which uses internal PHY. I can give you general instructions what to do, if you want.
  13. jernej

    Mainline VPU

    Rebase usually happens around the time of stable release. You'll wait for more than a month.
  14. jernej

    Mainline VPU

    Current master branch of gst-plugins-bad (what will land in next stable release) should already work pretty well with all stable codecs (MPEG2, H264 and VP8). HEVC patches won't help, because LE kernel patches add missing functionalities in API and those changes are naturally compatible only with ffmpeg patches from LE. But with every kernel release those patches get smaller.
  15. jernej

    Mainline VPU

    ffmpeg patches use only public, stable headers - at 5.14 that means MPEG2, VP8 and H264. For HEVC, ffmpeg patches contain their own copy of header file. That's why it's important to have matching kernel headers (for stable codecs) and LE patches (for unstable/non-public API and other improvements - if you care). AFAIK ffplay doesn't use HW acceleration. At least I never managed to force it. That's why I gave ffmpeg based test command. I can't help you with mpv... Only HEVC patches must be realigned, other codecs has been declared stable and thus API will not change. However, drivers implementing that API were improved in some areas.