jernej
-
Posts
1144 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jernej
-
-
I don't know this board, but it seems button is directly wired to reset pin, so reset is expected response. This board isn't the best choice for testing this. Maybe you can try with RTC wakeup. Or maybe even HDMI-CEC wakeup, but you need to change config for this one.
-
Which board do you use for testing?
-
Crust is successfully integrated on A64, H3, H5 and H6 in LibreELEC. R40 and H616 don't have co-processor, so they can't have it. I don't know A83T state. H3 needs additional U-Boot patches which are in conflict with other SoCs (including R40), so it's best to have them separated.
Easiest test is to use board with power button. Put board in sleep with "systemctl suspend" or power it down via command line (poweroff, shutdown now, etc.). Once it's in sleep or in stand by mode, press power button. If everything works as it should, board should come to life. Serial console is highly recommended during testing and a must for debugging any kind of issues.
-
No, that part is correct, but I must admit that since I have no system with patched ffmpeg at hand currently, I misremember how request api is expressed in ffmpeg decoders list. In any case, request api is covered by drm hwaccel and use drmprime pixel formats. Anyway, it seems you succeeded in reaching your goal.
-
9 hours ago, robertoj said:
Do I need to set CMA=128M in bootargs?
Not sure what are current defaults, but that's generally on the low side. LE uses CMA size of 384 MiB, mainly due to 4k.
9 hours ago, robertoj said:Checking the libreelec patches... I see that these linux files are patched:
Are they needed?
They fix one buffer management issue which may cause incorrect decoding but most importantly, they massively lower amount of memory that's used during decoding. Those fixes are included in 6.2 and newer kernels.
Use following command for testing:
ffmpeg -loglevel debug -hwaccel drm -hwaccel_output_format drm_prime -i video.mkv -f null -It will be pretty obvious from debug log if request api is used or not.
Not sure which version of mpv you're using, but very latest (not sure if it's in released version or in development branch) should allow using request api ffmpeg also when window manager is running.
EDIT: make sure that this ffmpeg patch is included: https://github.com/jernejsk/FFmpeg/commit/5057eb96b2adbff022a1abd8d5b06f369f908d51
-
*_v4l2m2m codecs are for v4l2 stateful drivers, not request api. Actually, you have to grep for "request" word. Check that you have 6.1 kernel headers installed. IIRC last important kernel patches went into 6.2, so ideally you would run that. Last but not least, to know which codecs are supported, you have to use v4l2-ctl command. Easiest way is to use --all parameter and check for supported formats on cedrus device.
-
Encoding is not supported by mainline driver. There are some hacks posted on this forum how to make it work using vendor driver, but you need to patch kernel and ffmpeg and you can only have encoding or decoding working, not both.
-
v4l2 request is already supported by gstreamer natively. Only question is if it's enabled in distributed binary.
-
CEC on H6 works just fine, as I used it many times, although not with Armbian. I can think of following reasons why CEC doesn't work:
1. make sure it's enabled in TV settings. I had to enable it on LG TV and old plasma TV. BEWARE: Setting is usually hidden under commercial name like simplink, easylink, etc.
2. make sure your libcec is new enough, at least 4.0.5
3. make sure driver is loaded (check for /dev/cec0)
4. it could be cable issue, although that's unlikely
-
2 hours ago, ByteAtATime said:
Does Armbian have any plans to create their own Mali drivers?
GPU drivers are one of the most complex drivers possible. Basically, you have to write compiler in mesa and task scheduler in kernel. So no.
-
-
That box is not officially supported, I believe. Which image do you use for it?
In any case, I never tested above patches with Armbian. Most likely they need some adjustments before they can be used with build system. Currently I'm busy with other things, hopefully someone else can help you integrate them.
-
-
Quick solution is to use LibreELEC... Currently a lot of patching is needed to make HW decoding work with Kodi, but fortunately, most of the patches are getting upstreamed, only outlier for now is ffmpeg.
-
well, I've been messing with Linux kernel and especially sunxi drivers for several years
-
That wiki article is missing explanation how to calculate pin number in case of multiple pin controllers. PL2 is on second controller, where first port is "L". So pin number calculation is actually 0 * 32 + 2 = 2.
-
H313 is basically the same as H616, so you can try any of those variants. But of course there is no guarantee any of it will work...
-
10 hours ago, rammfire said:
1024x768
That is default fallback resolution when kernel can't read resolution info from display (on all platforms and architectures). There can be multiple reasons, like cable, monitor, some kernel/driver issue...
-
Your understanding is incorrect:
1. VDPAU was used only with vendor kernel, which is obsolete for a long time. Armbian uses only mainline kernel.
2. No need to worry due to 1)
3. GPU doesn't do anything for video decoding. That's desktop PC concept. Embedded SoCs have dedicated VPUs (video processing unit). But it's true that ffmpeg need patching. More specifically, it needs v4l2 request api support.
4. That's not necessary if ffmpeg libraries are patched and installed system wide.
Last but not least, v4l2 request video decoding support is tested only in Kodi GBM mode. This means that it must be started from console, when no desktop environment is running. Maybe wayland mode would work, but I don't know. Certainly it won't work under X11. You have to use software decoding there.
-
AFAIK, mainline kernel isn't meant to be booted in secure mode and this is just to allow BSP kernel to be booted. I might be wrong, though. Just try running in non-sec mode.
-
13 hours ago, ning said:
hwdec not support X ot wayland.
That's not true anymore. MPV support it via GPU rendering in v0.35 for both, X and Wayland. However, you still need patched ffmpeg for that.
-
yes
-
On 7/21/2022 at 9:44 AM, amazingfate said:
You can play 1080p video with hardware decode using kodi.
Latest stable version of mpv also supports video playback with patched ffmpeg, even in x11 and wayland. If Armbian would package such ffmpeg, it would make almost trivial for people to watch movies using mpv on desktop.
-
1 hour ago, hotnikq said:
Mali gpu
It has nothing to do with video decoding. Read posts right before yours.
Need some pointers for testing crust
in NanoPi Duo2
Posted
Note that crust is very board specific. If it doesn't have IR by default, you have to enable it in config. Apart from that, you have also select correct IR protocol and key code. On some boards you also have to select proper clock for IR.