Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Slackwareaarch64. Kaffeine is working on slarm64, but I'm still having an issue playing local files. All the "support" packages (x264, etc) are the same on both. I fly out of the country at some ungodly hour of the morning tomorrow, and will be gone for a week, so further digging will have to await my return....
I usually rebuild all my third party packages on every large update when I have slackware current installed. It's usually brainless to do so with rarely any breakage. I use a slightly custom ffmpeg that I rebuild for h264, h265, aac, and fdk support on every upgrade. It doesn't matter how long these packages perform. Any dependency and target application will require this process. This is the case on any architecture be it arm, aarch64, x86, x86_64.
It doesn't matter if the target application and dependency chain hasn't changed. The operating system has, and may need to be told about the third party software again.
...It doesn't matter if the target application and dependency chain hasn't changed. The operating system has, and may need to be told about the third party software again.
I don't see the point myself. I've the same issue as PChristy: Slarm64 on a RazPi 4 with VLC-3.0.18, which won't play local mp4s or some mkvs, although it did before. I installed the slarm64-20230807 RPI-4 image, updated all packages to current, and this vlc fault developed. The VLC, libx264 & libx265 compile dates are all early 2023. I restored a backup from May 2023, and everything's fine.
The obvious question for me is: "what have I changed?" and the answer is just about everything. Are you suggesting I recompile the vlc, libx264, & libx265? They are the few items I can be sure of that work. MPV plays all videos. FFplay plays all videos. Binaries call subroutines from libraries for various functions and one or some of those functions are not working as expected. I don't think anything "needs to be told about" anything.
Has recompiling known working software ever fixed something for you? In as far as I have followed faults on current, problems have always been a bug introduced in some newly compiled package.
Do what you will. I am only making a friendly suggestion so future headaches can be avoided. Also, vlc is not included in Slackware for any architecture. You can look at mplayer as an example to see all the libraries that link to it on Slackware proper.
Log in as root:
Code:
ldd `which mplayer`
Or ffmpeg:
Code:
ldd `which ffmpeg`
You can run the same command for vlc and you will find what links to it. That is a foolproof way to see if vlc needs to be rebuilt due to changes in Slackware proper. Additionally, the vlc application is not part of Slackware. Whether the software works, is not of any interest to me. Maybe slarm64 includes it and builds a package for you. I have no interest in that. If it is broken on Slackware proper, I have no interest in that either. It is a third party application. In case you have done so, it is not recommended that you mix packages from slarm64 and slackwareaarch64.
EDIT: I forgot to mention: If you have 3rd party dependencies that vlc relies upon, then the same process should be applied. It is recommended they be rebuilt too when SA64 has an update that those depend on.
I'm not mixing with slackwareaarch64. Slackwareaarch64 stays pretty true to the x86_64 way of doing things, but SBCs differ wildly in the bootup phase. Slarm64 supplies binary images, which make it a much easier install, and it accomodates a wider range of sbcs. There is a riscv64 release also.
No packages outside of slackware current are needed to run vlc. For me, it's very simple: On my (Glibc-2.36) backup, vlc works on my RazPi, but palemoon won't work. On current (glibc-2.37), it's vice-versa. I prefer vlc, but have deleted my glibc-2.36 palemoon in error. I do have an ungoogled chromium. I have compiled none of these, I just installed packages on what is for me a media box.
vlc lists dependencies on only 12 libs, & very little of the AV stuff. ffmpeg and mplayer are notably more verbose. It's finding all the libs all right, just some new version is misbehaving. So vlc doesn't use it.
Last edited by business_kid; 09-14-2023 at 12:53 PM.
Well, as it happens there was an Slarm64 image for the RazPi released on 20230910. I had updated on 20230909, but there were also updates on 20230910. That image played the unplayable videos with my vlc. There's teething problems, of course, but not video playing ones.
Kaffeine and VLC are third party applications listed on slackbuilds.org. The aarch64 architecture is not officially supported on SlackBuilds.org either. You can try a report here in case they are broken on x86 too: https://www.linuxquestions.org/quest...ls-4175561999/
Other than that, you do not provide enough information for help.
Yes, I appreciate that. The biggest bug at present is the graphics drivers on Raspberry Pis, which no-one - except Libreelec - seems to have got a handle on. The board manufacturers claim its capable of 4K@60, but I've only ever seen that on Libreelec/Kodi. Even PiOS struggles at 1080, as does Slackwareaarch64, slarm64 and sarpi64. It seems to be something in the kernel, which shows no signs of being fixed soon. The slackwareaarch64 Pi kernel is MUCH better, but still struggles with the graphics driver.
Having said all that, it has been working until recently - pretty decently too. Certainly good enough to watch off-air TV in high definition. The problem seems to occur when SDL is updated. I thought at first it might be something to do with mesa, but the only candidate in the last updates has been SDL. At the moment, it plays the audio, but the video freezes - both off-air, and local files.
All seems to be fine on x86_64.
I have to go out this morning, but I'll leave VLC compiling - again(!) - and report back the outcome...
As you're on current, you could regress if you have the older packages. Do it with whatever older stuff you have. If you clean out, I've no bright ideas for you.
Be sure to recompile all third party packages related to vlc and Kaffiene. I wouldn't recommend doing it on a raspberry pi 4, unless its all you have. If you have multiple raspberry pis, whether its a 3 or 4 running aarch64, combine their speed with distccd.
I don't use the x-toolchain that often, but it should function. Stuart uses the x-toolchain to build stuff quickly. It builds a stack of gcc, binutils, and glibc for cross compiling packages from the sa64 main tree. It can be leveraged to use your 3rd party slackbuilds if you are motivated to do so.
I am not 100% sure I will, but I have plans to provide packages of software like vlc, libreoffice, and other time consuming packages. Possibly, chromium. However, I will not start work on such a repository until a stable release of Aarch64.
Last edited by mralk3; 10-03-2023 at 07:36 AM.
Reason: typo
Using cvlc to play a local h264/aac file produces the following errors:
Code:
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[0000000029503850] dummy interface: using the dummy interface module...
[0000007f64001e70] glconv_vaapi_x11 gl error: vaInitialize: unknown libva error
[0000007f64001e70] glconv_vaapi_drm gl error: vaInitialize: unknown libva error
[0000007f64001e70] glconv_vaapi_drm gl error: vaInitialize: unknown libva error
[0000007f64001e70] glconv_vaapi_drm gl error: vaInitialize: unknown libva error
[0000007f88c0b280] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f88c0b280] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f88c0b280] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f88c0b280] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f88c0b280] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f88c0b280] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f88c0b280] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f88c0b280] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
I think the va errors are a red herring, as they appeared even when VLC was working properly.
The avcodec errors imply a ffmpeg issue. However, ffplay and MPV play the same file without issue - which is really confusing me!
I think I'm just going to park this one and see if it resolves itself again in a future round of updates - like it did last time!
Would be nice to know what the root cause is, though...!
I was seeing some similar stuff when I had vlc issues. Also sound errors in dmesg, but sound was fine. Is there some debug option in vlc, as you're compiling it? I came to the conclusion that the errors reported were spurious, and I wasn't getting the ones that mattered.
What are you seeing onscreen while hearing the sound? Are any mkvs being affected?
Sound plays normally, but video comes up, plays a couple of frames, then freezes.
I'm beginning to think its not something that VLC directly depends on, but something that one of the dependencies depends on - if you get my drift!
We should find out in a day or two, as SDL has just been upgraded in Slackware. My hunch has been that SDL is connected to this somehow, so it will be interesting to see if the problem goes away when SDL is updated in aarch64....
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.