libX265 for ffmpeg? [& later: RazPi Graphics]
 

Is the h265 codec(?) compiled for slarm64? I'm getting I've been reducing the size of some videos. It started with ten 1 hour things @ ~4GB each which shrank to ~400MB with h264 --> h265 conversion.

They took over 20 minutes each on my 6 core box @3.5Ghz using 850-1100% cpu averaging 2.5x normal speed while converting.

I wanted to try one on my RazPi for comparison purposes, but ffmpeg is embarrassed for the h265 encoder. It might compete with my old twin core laptop.


Edit: forgot to post the command:

I just had a look on my rpi4.
So it looks to be available with hevc and hevc_v4l2m2m for decode and hevc_v4l2m2m for encode. I am not so sure hevc_vaapi will get you anything unless it is just a wrapper. I am no expert but I did try using hevc instad of lib265 and it failed - but it did try with:- I think I have reached the limit of my knowledge.

Dunc.

Thanks for the fast reply. The video was actually 4.2G. I found my AMD box had Alien Bob's libX265, so I looked up the package, and got this: The one line I took from videolan.org was So Slackware never had libX265.
I never go too far on these timings tests. I will compile libX265 for it, but not ffmpeg. I'm ok, because I'm comparing myself with myself. Otherwise,these timing comparisons usually deteriorate into a little boy's "Whose willy is biggest?" competion:rolleyes:

Edit: Unnecessary Post - ignore

OK this thread is finished from my POV for the moment. Not sorted, but finished.

I'm using a binary image from around the time of the 15.0 release with a slightly updated kernel. But it's light on development stuff. I tried building, but cmake puked thusly It seems the binary image was a bit light on development stuff. I had to install cmake, nasm & yasm to get off the ground, now I'm light on gcc-g++ & clang++. It seems the logical thing to do is mirror the 15.0-aarch64 packages from slackware.uk and run a mass 'upgradepkg --install-new' when I get time. I have a backup as it stands so I can always revert. I have 6.8G spare on my 20G / & 42G spare on my /home so I'll have the space. But timing tests are very low on the priorities.

build script, x265-3.5-aarch64-1mara.txz

Thanks for the reply - you seem to have an impressively huge repo there of packages.

To business, though: This command still returns this error I did the usual stuff - running ldconfig, and a reboot, but the error remains. I even ssh'ed in to my x86_64 box and checked the libraries were identically named, which they are.

Does this mean I have to recompile ffmpeg?

yes.

OK. I won't because it's not worth the bother for an unimportant timing test. Better Arm systems are here and will come. If it was handy, I would have tested conversion speed.

Thanks for your help, nevertheless. Maybe add that option to whatever ffmpeg script you use?

all slarm64 uses original slackware64 scripts.

I hear you. My x86_64 ffmpeg is one of Alien Bob's 'unrestricted' builds as Europe isn't so Nazi on copyright as the Excited States. Perhaps that's where the difference is.

Anyhow, we have the answer. I could just add libx265 to the unrestricted ffmpeg build on x86_64 and ffmpeg picked it up, whereas yours didn't. I gather it's the restricted build for the U.S. It's your choice what you distribute, of course. The other items to get restricted/unrestricted treatment were vlc and iirc some of the gst plugins. Alien does _a_lot_ of audio stuff so there could be others.

You may be able to farm out doing alternative builds to whoever maintains the 'slackware.uk/slarm64' mirror site? None of the codecs are restricted there, but they are copyrighted in the US.

there are no restrictions.

I always build (or re-build) ffmpeg to include x264, x265, xvidcore, and a whole host of other video related stuff.

SBo builds are available for most of these libraries, and are simple to modify for aarch64 architecture, though in the past I've also modified standard Slackware build scripts for my purpose.

The standard Slackware build script has options to re-build ffmpeg in localities where things are less restrictive. It is not difficult to do. However, build times on a Pi are quite long compared to even modest x86_64 systems!

If you build these things yourself, you will know that they are optimised for your hardware. Generic builds are OK, but can be "over-engineered". For example, AlienBob's VLC is a monster, though it does cover all bases on x86_64!

--
Pete

Not me.
I'd build for needs, and this is not a need. I think I built Quartus fpga software, which was a 15G download. But to be fair, most of that was chip data. My install was a 15.0 binary image which has to be upgraded to include the rest of 15.0. I'll pass on the timing test. I built ffmpeg before, and while not difficult, it was work

On my standard AMD box (Ryzen 5 5600 6 cores/12 threads@3.5Ghz with 16G & nvme) it took over 20 minutes to convert a particular video from h264 to h265. The space saving was 4.0GB --> ~400Megs. I just wondered how long the Pi would take to do it, but I'm not building ffmpeg for that.

EDIT: Yes, Alien's unrestricted build is huge. But it's a Swiss Army knife. His unrestricted ffmpeg is the same - hence it's attractiveness.

Now that I have you, it's possible the slarm64 vlc won't play h265 videos. That's my media box. So I might have to switch them to something else. I'll have to find a good alternative that the Pi handles.

My Pi 400 plays x265 just fine - with one proviso: It struggles with 4K! That has nothing to do with the media player or x265, but is a problem with the graphics driver. Even 1080 videos on mine have all four cores running at 80%+ simply because the hardware acceleration is not working yet. I don't think its working on any of the 64-bit distros, not even Pi's own! Slarm64 at least tries to play 4K, although it is VERY jittery.

SLackwareaarch64 can't even play 1080 on my system, and struggles with 720!

We are promised better hardware graphics support in kernel 5.20/6 which is due in a month or so's time.

The problem seems to be the Broadcom graphics chip. Although it is (allegedly) 4K capable, they have been slow/reluctant to release drivers for it. I'm not sure if the promised kernel drivers are reverse engineered or official releases. I guess we won't know if they work until they land...

--
Pete