jernej
-
Posts
1151 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jernej
-
-
9 hours ago, greenais said:
So you mean that even in vendor's preinstalled Android they don't use GPU for that?
Even if this is now more than 10 years old, this is still mandatory read: https://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/
9 hours ago, greenais said:I installed there VLC + couple of players from vanilla stores - all of them have no issues with HW decoding at all...
All of these players use Android API, so they don't need to care how HW video decoding is really done. Android is modified in a way to use Cedar core for that.
9 hours ago, greenais said:According to their status Cedrus could be much easier way - VLC stated there as supported already
libVA backend isn't maintained and LE doesn't use it. Latest kernel are not supported in that v4l2_request libVA port. For VLC and other players it would be easier to use it, but that's life...
There is more than enough information to figure out how this works, but granted, there is also a lot of obsolete information, so you have to figure how things work. Hint, VLC currently won't work with Cedrus.
-
@Troy H If you want mediacenter distro, you can try LibreELEC with Kodi. It has proper OPi3 LTS support (except wifi), but it might not be to your liking because it's single minded distro - no package manager to install extra software. If you decide to try it, I suggest latest nightly image (mind the date!) until 12.0.2 is out, as it has one important video rendering fix.
-
18 hours ago, greenais said:
Hi @jernej could you elaborate perhaps what have been done on LibreELEC side to get hardware acceleration work on OPi3-LTS? Is it somehow related to v4l2_request module for VA drivers which was mentioned in several other treads elsewhere?
LE doesn't use VAAPI as it would be just extra complication where something could go wrong. At the time LE started supporting v4l2_request based drivers, v4l2 wasn't flexible enough to support VAAPI way of memory management, at least not in all cases. Instead, LE uses modified ffmpeg with native v4l2_request support, among some other modifications. Patches are available here. In some cases Kodi also need patches (for example, for HW deinterlacing.)
18 hours ago, greenais said:To my point there is quite little we can expect here from Debian Panfrost guys, they clearly stated that HW acceleration is out of their focus at all (yet? for years already)
They are right, because Mali GPU has nothing to do with HW video decoding. It can be used for video rendering, but even that is done with DRM planes on LE, which is more performant in most (all?) cases. Allwinner SoCs use Cedrus core for video decoding. LE uses GPU only for GUI rendering.
-
On 11/9/2024 at 7:41 PM, Nick A said:
I haven't looked into the mixer1 part of the patch. Not sure if H616/H618 has one. I can't find the base address in the H616 user manual.
It has, all H family has 2 mixers. Addresses are hidden in DE BSP source code, but not as absolute address, only as relative. In any case, you don't need second mixer if you won't use any other display output.
Note that there is no documentation for DE3.3. There is documentation for DE3 on linux-sunxi.org, which is older, but nevertheless similar core. Still, BSP source code will give you best info, even if it's sometimes hard to understand.
In any case, you seem to be on right track to get it working. I strongly suggest that you dump register values of all components involved in pipeline from working BSP solution (most likely Android image) and compare to them to register values dump from your mainline based system. This includes TVE, TCON top and also very importantly, clocks and resets.
One extremely useful trick for diagnostics is to use TCON test patterns. Those patterns are directly generated in TCON and then piped to encoder, TVE in this case. It allows you to test TVE without worrying about mixer and if it's properly routed through TCON top. Those test patterns can be enabled by setting TCON register 0x40 to, for example, 1, which will get you well know color check pattern.
Note that your solution with TV TOP included in same driver as TVE will work here, but it's not appropriate solution for upstream. TV TOP should be standalone driver like TCON TOP...
-
If you want Kodi and smooth video playback, you can always check LibreELEC. OPi3-LTS has some bugs, so best build is here, but you can wait for next point release which will be done in about a week.
Video playback needs some work in progress software if you want smooth experience, which afaik is not present (yet) in Armbian.
-
I don't have neither of these boards, but I can help answering any question regarding state of the art drivers in mainline kernel.
-
1 hour ago, Gunjan Gupta said:
I will also test if the system resumes on IR once that arrives
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.
-
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...
Is it possible to play videos with Kodi on Orange Pi 3 LTS ?
in Allwinner sunxi
Posted
Yes, H616 Cedrus is capable of decoding VP9, but I'm not aware that anyone actually implemented support for it.