jernej

  • Posts

    1033
  • Joined

  • Last visited

Everything posted by jernej

  1. jernej

    Mainline VPU

    Rebase usually happens around the time of stable release. You'll wait for more than a month.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. jernej

    Mainline VPU

    You are using sources meant to be used on 5.14.
  10. 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.
  11. I'm pretty sure you didn't try to compile "v4l2-request-hwaccel-4.3.1-new" branch or you modified it. Obviously, you have old branch with its own h264 control definitions and new kernel, which have them in uapi. Make sure there is no h264-ctrls.h file in libavcodec. If it is, you have wrong branch or you tried to mix some branches and/or patches together. FYI, I don't care about mpv, so you'll have to make it work yourself. I can only help you build ffmpeg.
  12. 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.
  13. 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.
  14. Latest versions are actually less featureful because it's easier to merge series if there is less patches and thus more consensus how to do things. I can't tell which is the most featureful branch from the top of my head, probably v6 or v7. Certainly last variant contain no USB support.
  15. Sorry, I have no idea. I don't use desktop environment on ARM boards at all and I don't have this particular board.
  16. jernej

    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.
  17. 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.
  18. disp_mode trick doesn't work with mainline kernels. There are two ways that I know, both via kernel boot arguments: 1. Specify preferred video mode: "video=HDMI-A-1:800x480" 2. override EDID data, like described here. Note that I tested only second approach on different distro. First one should work, but maybe syntax is not completely correct (google is your friend here). Another note, if resolution you want to set is not reported by your monitor, only second approach will work.
  19. well. I don't have this particular board to test resulting image.
  20. 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...
  21. Yes, I do In short, if you only have 1024x768 resolution, that means that board was unable to read EDID data from monitor (it holds info which resolutions are supported by monitor and a few other things). It's a bit weird that this doesn't work. I would try with different HDMI cable and if your cable is long, I would try with a short one. It's also possible that DDC lines are fried due to ESD. Of course it could also be a driver bug, but I have never observed such issue on my boards.
  22. 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.
  23. According to https://linux-sunxi.org/Tanix_TX6 there are two versions of the box, 2 GiB and 4 GiB of RAM. RAM size detection code on H6 should be pretty solid these days, but if you really think you have 4 GiB version, open the box and provide clear images of both board sides. That way we could count RAM chips and check markings on them to manually calculate RAM size and if it's incorrect, to get at least some idea what could be wrong. P.S: Boards really do have 4 GiB of RAM, it's just that H6 can use only 3 GiB.
  24. jernej

    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.
  25. I have troubles booting Tritium H5 myself, but from SD card. I just power cycle it until it works. Sometimes it seems that it helps if HDMI is unplugged, but that might be just red herring. However, once it's booted, all reboots, suspend/resume cycles via Crust work. I have no idea why it's behaving that way.