jernej

Members
  • Content Count

    932
  • Joined

  • Last visited

4 Followers

About jernej

  • Rank
    Embedded member

Recent Profile Visitors

5036 profile views
  1. jernej

    Mainline VPU

    AFAIK HEVC is not yet supported in RK driver but some WIP patches exists. Try H264 first.
  2. jernej

    Mainline VPU

    Well, DRM PRIME acceleration is the most efficient one for ARM boards and disabling it means that CPU will use much more resources than it's needed. In fact, v4l2-request hwaccel patches for ffmpeg were developed together with DRM PRIME acceleration in Kodi. Note that DRM PRIME acceleration consists of two parts: 1. DRM PRIME HW decoding 2. DRM PRIME zero-copy rendering First one is absolutely necessary to have it enabled, otherwise VPU won't be used and instead video will be SW decoded. Second one is still very important - it bypasses GPU for rendering and in
  3. Sadly noone maintain vaapi layer, so you're mostly on your own there, which means learning a ton of internal details of vaapi, v4l2 request api and supported codecs. On the other hand, ffmpeg fork with v4l2 request api is pretty well maintained. I know this is not ideal, but for example mpv (with one patch) can work with that modified ffmpeg.
  4. Note that @Kwiboo's ffmpeg is assuming that kernel is patched with some out-of-tree patches (you can find them in LibreELEC build system). For example, if you remove this commit, output should be much better, but that would mean that interlaced videos will be decoded incorrectly. Good news is that with Linux 5.10 H264 API will be aligned and no out-of-tree patches will be necessary anymore.
  5. I mean flags in source, not compile flags. Check what has been removed in h265.c and restore it, with new flag or field names.
  6. mpv uses system ffmpeg libraries, so you have to re-compile ffmpeg package with v4l2 request api patches. You need this mpv patch.
  7. BTW, while your approach may work to some degree, note that you don't set bunch of flags for h265. This may work only in very specific cases. Certainly h265 should be worse than before.
  8. Basically yes. Note that kernel patches are only for improvements - fixing decoding issues. At least H264 API should be promoted to stable with kernel 5.10, maybe others too. Any player which uses ffmpeg directly should be able to benefit from those patches. AFAIK mpv needs only one simple patch in order to use this chain. I have no idea about VLC internals so I can't say much about it. About VAAPI - request API (Cedrus implements it for decoding) is similar in terms of requirements and features to VAAPI so Bootlin created simple library to expose it. That way they could use any VA
  9. Note that ffmpeg patches for request API are important - without patched ffmpeg, all kernel patches have no meaning. Second important thing is that LibreELEC runs Kodi without X11 for ARM boards - this allows to use display more efficiently. On X11 it would be needed to render video through GPU which is less efficient. Note that I never actually tried that.
  10. To enable HDMI in U-Boot for any A64 board you have to first enable DE2 driver in config file and then somehow enable voltage regulator responsible for HDMI power (this is main reason why it's not currently supported). U-Boot doesn't have AXP803 driver. Probably easiest way would be to modify ATF.
  11. Given than GPU DVFS is not in mainline yet, I think best solution would be to remove those patches from Armbian build system and maybe add a patch which would increase frequency and adjust voltage...
  12. GPU, Display Engine and HDMI all have different clock sources. It could still be HDMI clock issue, just different...
  13. In the past, I tested @Clément Peron's patches on Tanix TX6 which has fixed GPU regulator and it has same problem. I'm pretty sure at this point that it's clock driver issue.
  14. Well, kernel modification is needed for better decoding (less glitches). Probably new *-ctrl.h files contain new fields (not 100% sure) which also need to be filled. There is no any post processing implemented here like scaling. It would be possible to do that via SoC specific peripherals but that wouldn't be universal and thus it's out of scope of this library. Anyway, I'm glad you succeeded.
  15. Sorry, no. I never worked with AC108, 3.10 kernel or Android on Allwinner boards. Just mainline kernel (currently 5.7), proper Linux (no Android) and only codec I have experience with is DW-HDMI for audio over HDMI.