jernej
-
Posts
1024 -
Joined
-
Last visited
Posts posted by jernej
-
-
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.
-
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.
-
6 hours ago, Dan MacDonald said:
I would like to use the cedrus hw video decoder to play 4K h264 videos with mpv on my T95 Max.
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.
-
On 8/12/2021 at 6:01 AM, Werner said:
Linux sources from apritzel are most up-to-date AFAIK with h616-v9 branch or whatever number he is currently working on.
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.
-
20 hours ago, rubenvb said:
HEVC content still just doesn't render at all, but maybe I need some extra kernel patches for that still.
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.
20 hours ago, rubenvb said:Thanks for the link to the up to date FFmpeg patches, you're a lifesaver!
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.
-
On 7/11/2021 at 7:55 PM, hcac said:
I set the resolution in boot parameters.
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...
-
On 7/16/2021 at 5:56 PM, forever_ noob said:
@jernej , you seem like a man who could know more about this
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.
-
1 hour ago, ngocdungvn said:
Hope for the future, Tx6 can detect its full 4GB of 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.
-
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.
-
3 hours ago, rubenvb said:
only the "outdated" (mismatching with kernels >=5.11) in the LibreElec repos.
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.
-
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.
-
1 hour ago, Clonazepunk said:
Gigabits (GiB), not Gigabytes (GB)
That's not correct - distinction between bytes (B) and bits (b) is just upper and lower case. Prefix "Gi" means gibi and it means factor of 1024 * 1024 and second one is giga which means factor 1000 * 1000.
-
H616 ATF stuff should be upstreamed already, but I'm not sure if it is in any stable version.
-
2 hours ago, MX_Master said:
I need your help. guys. Any suggestions how to switch H6's ARISC (CPUS) clock to the PERIPH0 PLL? Is it possible this memory region is protected from uboot and linux kernel?
If I'm not mistaken, yes. You can always make a SPL hack, which do stuff with otherwise protected resources.
-
4 hours ago, EndlessEden said:Quote
passthrough on RK 4.4 kernel uses custom approach. Kodi would need adjustments to use it.
Any information on this? - Mainline has some better cpu performance, but GPU side of things with panfrost is not well integrated. My testing using kodi on non-legacy builds of armbian and even attempts at archlinux(arm), have shown me that VPU(VideoDecoder) seems to be a mess on the oss side of things, so proprietary drivers seem to be the only way to a functional experience.
I wouldn't say mess, just work in progress - with 5.13, MPEG2, VP8 and H264 will be all stable (no need to patch anything), with HEVC and VP9 being in development (most or all supported features reachable with out of tree patches).
Anyway, regarding passthrough - I can give you only a hint from source, since I don't have any intention of running BSP RK kernel: https://github.com/rockchip-linux/kernel/blob/develop-4.4/sound/soc/codecs/hdmi-codec.c#L126 You can set this with amixer - 0 means PCM, 1 means NLPCM and 2 means HBR NLPCM. I have no idea how to properly use it.
-
@tony013 Fix for RK3399 HDMI audio on mainline has been just merged in LE: https://github.com/LibreELEC/LibreELEC.tv/pull/5365
-
I was speaking about SoC capabilities with first part, not about Armbian setup. Second part is speaking about my experiments about passthrough on mainline.
-
Yeah, I realized that this topic is about BSP kernel after posting. There will be no more work done for it in LE, next RK release will use mainline. I believe deinterlacing also doesn't work here in Kodi, right?
-
In short, HW decoding on ARM boards is messy at this moment (check this summary). I'm not sure you'll get far with Kodi on Armbian. LibreELEC uses a lot of out-of-tree ffmpeg and kernel patches to achieve good Kodi overall performance (they are being gradually upstreamed, but that takes time), so I suggest you try that image first.
Note: Passthrough on RK3399 is possible - it uses similar peripherals and concept as Allwinner H6, for which I have experimental passthrough patches, even for HBR. But that also needs proper ALSA config, where I have issues...
EDIT: I'm talking about mainline kernels - passthrough on RK 4.4 kernel uses custom approach. Kodi would need adjustments to use it.
-
No, wifi is not yet supported, it needs some out of tree driver. I don't think anyone bothered to try it out (I'm big skeptic about these wifi modules...).
4kp30 video on Orange Pi Lite and mainline hardware acceleration
in Allwinner H2 & H3
Posted
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.