New to Manjaro, but not new to Linux by a long shot.
I wanted to compile a custom ffmpeg with some patches for hwaccel on a PBP. I want to get the source for the Manjaro package (i.e., PKGBUILD file), since I want to make a properly packaged version. It looks like there’s no equivalent of
dnf download --source with
pacman to get it automatically.
Some googling leads me to “asp”. That works! But this ffmpeg will clearly only build on x86_64 and not aarch64. x86_64 is the only arch listed and some of the configure options are x86 only.
And this appears to be because asp just gets an Arch package, and they only do x86_64. If I want the Manjaro package, I need to go hunt on gitlab for it.
So I do that, and there is no ffmpeg package. Nothing for arm in fact, no kernel, no nothing… And this is because there is another gitlab for Manjaro ARM! A package can’t build for both from the same source? Seems like a lot of duplicated package building code. I look in there, find the kernel package and other things, but still no ffmpeg.
So where the heck is it??? I know it exists because I’ve got the package installed!
Is there some automatic way to find the corresponding source from the binary package file? Like how a binary RPM has the SRPM name in the metadata. Or is there some more reliable tool to get the source, like
dnf download or
asp, rather than manually hunting in gitlab?
I don’t know about Manjaro ARM, but here’s the Arch ARM ffmpeg:
This is exactly the first thing I did. It checks out the x86_64 version of the ffmpeg git repo from Arch.
@jabber found the correct repo. I didn’t know about the arch arm repositories. There’s not exactly a lot of links to them.
Still, is there no way to get the source automatically? Without manually searching at least four different sites?
im running it for v4l2 hardware transcoding on my minimal install and its working good.
sudo pacman -S ffmpeg
You can add aarch64 in arch=()
Or just do
makepkg -A to ignore the arch variable in PKGBUILD so it will use the host arch.
If you want to build it with v4l2_request for rk3399 then good luck even I want to give it another try.
You can also follow this work done be a community user on pine64
All the best
I’ve already modified it to build on aarch64 and added the patches for v4l2_request support. mpeg2 hardware decode on hantro works, but nothing else does.
But my question wasn’t how to build ffmpeg, but rather how one finds the correct source to the package. asp doesn’t appear to work since it only looks in the main x86_64 arch repo and ignores arch-arm, manjaro, and manjaro-arm.
I think I got hwaccell working with mpv and this ffmpeg fork. I haven’t done any measurements, but it seems that battery usage when watching movies lowered significantly. Either that, or I wanted to believe that really hard:D
Thanks for sharing I will try it tomorrow, if I get time.
Which codec did you test on with what video resolution?
I doubt on this coz you will need to compile mpv with v4l2—request enabled too.
I will try it myself tomorrow.
Update : it’s a very old pkg we can try it on latest package with v4l2—request enabled and its patched which are already in pr.
That is ffmpeg 4.2.2 with v4l2_request. I tried the latest one, 4.3, with v4l2_request and rkvdec patches.
While mpv will play with
--hwdec=drm, it’s not using hardware decoding. Enable verbose messages. It falls back to software.
Thought so, thanks for trying
Can you try from the link I shared?
To measure, try something like:
time mpv --framedrop=no --length=30 --no-audio ...other options...
That will play 30 seconds with no audio and no framedrops, and report the user and sys time, add those two times together to get how much CPU was spent to play the video. It should change pretty dramatically with hardware decoding. The frame drop and audio makes it more accurate, but doesn’t really make much different. The frequency scaling of the CPUs messes up the pure time measurement, but they pretty much run at full speed to keep up with HD video, so it still works pretty well.
On a PBP for 720p60 video, I get this for software decoding and vo=gpu:
- MPEG2: 43 seconds per 30 seconds = 1.43
- H264: 50 seconds per 30 seconds = 1.67
- H265: 94 seconds per 30 seconds = 3.13
With hardware decoding, it should be more like 15 seconds.
I built that older version of ffmpeg, still no acceleration with mpv with the Xorg/KDE desktop. It might be different with Wayland or on the console.
With mpv, no hw accel with mpeg2, h264, and h265. Same or slightly worse times than in my reply to @brzegorz above.
With ffmpeg directly, there is hw accelerated mpeg2 and h264 decode, but not h265. To test ffmpeg, I used:
time ffmpeg -hwaccel drm -i testfile.mkv -t 30 -an -f null -
Then added up the user and sys time and divide by 30 to get CPU seconds per second of video. With hwaccel it’s MPEG2 0.223 and H264 0.290. Without hwaccel it’s .550 and 1.237. And for H265, where hwaccel doesn’t work, it’s 2.483. So hwaccel provides about a 2x speedup for MPEG2 and 4x for H264. I didn’t bother with vp8 or vp9, but I think in theory they are supposed to be possible too.
This means you need to compile mpv and kodi with v4l2_request support.
How does one compile mpv with v4l2_request support? I see no option in mpv and no references to v4l2_request at all in the mpv source code. Are there patches somewhere? I’ve searched but haven’t found any.
Sorry for leading you into a rabbit hole - seems like my placebo was strong. Thanks for doing the tests:). Could you share PKGBUILD’s, or even add them to AUR, once you’re done? I’d be happy to enable it for real this time, and it’s one of the notorious questions here and on Pine forums.
I have patched the kernel with rk3399s rkvdec and hantro patch, this gives us kernel module needed for vpu support.
I also tried a patched version of ffmpeg and it doesn’t seem to pick v4l2_request like it used to do before.
I will upload the pkgbuild for kernel and ffmpeg so someone can play around with it.
Is this a special rkvdec kernel or just the normal Manjaro ARM kernel?
Is there a git repo of the Manjaro ARM kernel somewhere? I know about the manjaro arm package of the kernel, but I’d much rather work with the kernel source code itself in a git repo. Importing all the patches into git was a PITA since they aren’t all valid git commits and require manual action.
Its a manjaro kernel with rkvdec patches.
I have pushed it to
I meant the kernel code itself in git. Like this, GitHub - xyzzy42/linux at manjaro-arm-5.9.10-2
I made that from an older release. It a pain to keep up to date because the manjaro patches don’t apply cleanly and aren’t even all git patches.
Using just the PKGBUILD system, any update requires one to wipe the kernel tree, re-extract, re-patch, and totally re-build, which takes hours on a PBP.
With the kernel code in git, you can pull a new kernel update into the existing build tree and only recompile the changed files and it takes a minute to test a new kernel instead of hours.
Is it not the case that Manjaro must make the source code available under the GPL licenses?