Jump to content


  • Posts

  • Joined

  • Last visited

Other groups



Recent Profile Visitors

30881 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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. 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
  6. *_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.
  7. 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.
  8. v4l2 request is already supported by gstreamer natively. Only question is if it's enabled in distributed binary.
  9. 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
  10. 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.
  11. Times are changing, read this, this and this. Far from being able to use it out of the box, but it's possible.
  12. 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.
  13. I'm not "that" member, but I have somewhat working patches for analogue audio here. It should work for most cases, only issues that I have is setting up values at power up. With proper alsa config these issues can be offset.
  14. 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.
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines