jernej

  • Posts

    1048
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by jernej

  1. In theory, yes. As long as it has DDR3 RAM (no other RAM type is supported currently). Not to my knowledge.
  2. Nothing out of the box, but someone forward ported BSP driver to mainline and used that with encoding software that was developed back then. However, if you do that, you would lose mainline Cedrus driver (you can't have two drivers loaded for same core). I didn't try it myself, so I suggest you search this forum. IIRC it was discussed on this forum somewhere.
  3. jernej

    Mainline VPU

    GPU rendering is usually preferred in X11 environment. I don't think DRM rendering is implemented in most players under X11. Another common reason would be to use various fancy shaders for post-processing, for features that are not yet supported in driver or not at all in HW.
  4. 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.
  5. 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.
  6. 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...
  7. 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).
  8. Did anyone actually bother to port AW859A driver to mainline? I certainly didn't.
  9. 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).
  10. Sorry, I don't know. I don't use X11 nor displays via SPI.
  11. 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.
  12. sorry, I'm occupied with other work.
  13. 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.
  14. Yes, TX6 uses DDR3, whereas OPi3 uses LPDDR3 IIRC. Is there TX6 support? If so, you just need to copy ethernet part in DT.
  15. 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.
  16. jernej

    Mainline VPU

    Rebase usually happens around the time of stable release. You'll wait for more than a month.
  17. 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.
  18. 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.
  19. jernej

    Mainline VPU

    Ah, good to know. BTW, that's not only for Cedrus but for rkvdec and Hantro drivers too. They all provide same interface. It would be nice to see that more detailed log.
  20. Make sure you have big enough CMA region, either via kernel config or using kernel argument. I suggest 128 MiB, but if it still doesn't work, try bigger.
  21. jernej

    Mainline VPU

    Note that this is pure decoding speed (which can be optimized further). Rendering may add additional overhead. Last time I heard, this patch was needed: https://github.com/Kwiboo/mpv/commit/91f2b090eef12f48cf1d9e9157e5eefe6a60be6a If this doesn't work, then I don't know. Note that ffmpeg request api support is still experimental. It's quiet likely patches will be rewritten before they will be submitted to ffmpeg mailing list again. That's why there is no official support for it in any player. You are very lucky that somebody in the past actually looked into mpv. LE switched to 5.14 last week, so patches are already in. RK patches are here: https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches/linux/default I suggest taking at least v4l patches.
  22. jernej

    Mainline VPU

    Test command would be something like: ffmpeg -loglevel debug -hwaccel drm -hwaccel_output_format drm_prime -i video.mkv -f null - I think it should be pretty self evident from the log if request api is used or not. Notes: 1. If you don't use LE kernel patches, decoding interlaced H264 content won't work on RK. HEVC also won't work without kernel patches. 2. mpv most probably needs patching. At least it did in the past.
  23. jernej

    Mainline VPU

    I guess this branch should work: https://github.com/jernejsk/FFmpeg/commits/v4l2-request-hwaccel-4.3.1-new 5.13 is not something we cared for at LE (no build contains that version). This branch will be removed in near future.
  24. jernej

    Mainline VPU

    You are using sources meant to be used on 5.14.
  25. Nothing besides libdrm and libudev (should be part of systemd). Strange. Which kernel are you using? That branch was tested against 5.13 but it should work also against 5.12. What does "-re" parameter? Please add "-loglevel debug" and post debug log.