jernej
-
Posts
1144 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by jernej
-
sorry, I'm occupied with other work.
-
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.
-
Yes, TX6 uses DDR3, whereas OPi3 uses LPDDR3 IIRC. Is there TX6 support? If so, you just need to copy ethernet part in DT.
-
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.
-
Rebase usually happens around the time of stable release. You'll wait for more than a month.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
You are using sources meant to be used on 5.14.
-
4kp30 video on Orange Pi Lite and mainline hardware acceleration
jernej replied to genesys's topic in Allwinner sunxi
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. -
4kp30 video on Orange Pi Lite and mainline hardware acceleration
jernej replied to genesys's topic in Allwinner sunxi
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. -
4kp30 video on Orange Pi Lite and mainline hardware acceleration
jernej replied to genesys's topic in Allwinner sunxi
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. -
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.
-
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.
-
Sorry, I have no idea. I don't use desktop environment on ARM boards at all and I don't have this particular board.
-
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.
-
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.
-
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.
-
well. I don't have this particular board to test resulting image.
-
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...
-
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.