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.
System: Pi400, Slackwareaarch64-current (up to date), Pi-kernel, VLC-3.0.18
Something recent has broken VLC's ability to playback h264 files. This is a particular issue as I use Kaffeine (which uses libvlc) to watch TV occasionally, and I can no longer watch HD channels (SD is fine!).
I'm also unable to play local H264 files.
Smplayer+MPV, standalone MPV and ffplay all play h264 files fine, although cpu usage seems to have gone up (around 80% on all 4 cores). It seems as if something specific has broken VLC.
I've recompiled VLC, ffmpeg and x264 to no avail, and I've now run out of ideas!
VLC errors on a local file:
Code:
cvlc combat.mp4
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[000000001d319d60] dummy interface: using the dummy interface module...
[000000001d2fb560] vlcpulse audio output error: digital pass-through stream connection failure: Not supported
[000000001d2fb560] main audio output error: module not functional
[0000007f792b0c20] main decoder error: failed to create audio output
[0000007f5c001e50] glconv_vaapi_x11 gl error: vaInitialize: unknown libva error
[0000007f5c001e50] glconv_vaapi_drm gl error: vaInitialize: unknown libva error
[0000007f5c001e50] glconv_vaapi_drm gl error: vaInitialize: unknown libva error
[0000007f5c001e50] glconv_vaapi_drm gl error: vaInitialize: unknown libva error
Failed to open VDPAU backend libvdpau_vc4.so: cannot open shared object file: No such file or directory
[h264 @ 0x7f78e838a0] mmco: unref short failure
[h264 @ 0x7f791e3ae0] co located POCs unavailable
[h264 @ 0x7f791e3ae0] co located POCs unavailable
[h264 @ 0x7f78e838a0] mmco: unref short failure
[h264 @ 0x7f78e838a0] co located POCs unavailable
[h264 @ 0x7f78e838a0] co located POCs unavailable
[h264 @ 0x7f78f7c990] mmco: unref short failure
[h264 @ 0x7f78e838a0] co located POCs unavailable
[h264 @ 0x7f78f7c990] mmco: unref short failure
[h264 @ 0x7f79049a00] co located POCs unavailable
[h264 @ 0x7f78f7c990] co located POCs unavailable
[h264 @ 0x7f79116a70] co located POCs unavailable
[0000007f78c0ba20] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f78c0ba20] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f78c0ba20] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f78c0ba20] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
I'm using the "automatic" or "opengl" output, as recommended for this application. I don't think the va/vdpau errors are significant as I've seen these previously without issue. What I don't understand is the h264 errors, when mpv, ffplay, et al, play back just fine!
Anyone got any ideas?
--
Pete
Last edited by pchristy; 08-31-2023 at 06:51 AM.
Reason: update
How are you building vlc? From slackbuilds.org? Or using alienBob's build scripts? Your own slackbuild scripts?
Is it possible your packages are storing libs in /usr/lib?
For the most part the following works for me:
Code:
cd slackbuilds
git checkout -b aarch64
sed -i 's/x86_/aarch/g' */*.SlackBuild
git add .
git commit -m "switch to aarch64"
Then build any SlackBuild. Without these steps, stuff is put into /usr/lib, rather than /usr/lib64. I use sbopkg most of the time. There are a few build scripts that do require more adjustments, but the majority work fine on aarch64 with those changes.
Firstly, it has all been working perfectly for quite some time. It only broke after the recent updates - and only for H264 (haven't tried H265 yet, must do so!).
I'm building using the standard SBo script, only modified to add aarch64 to the processor options:
Code:
if [ "$ARCH" = "i586" ]; then
SLKCFLAGS="-O2 -march=i586 -mtune=i686"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
SLKCFLAGS="-O2 -fPIC"
LIBDIRSUFFIX="64"
elif [ "$ARCH" = "aarch64" ]; then
SLKCFLAGS="-O3 -fPIC"
LIBDIRSUFFIX="64"
else
SLKCFLAGS="-O2"
LIBDIRSUFFIX=""
fi
SLKCFLAGS is set to 03 following sndwvs slackbuild from slarm64 - which is also suffering the same issue, incidentally, also following a recent upgrade.
The SBo script is derived from AlienBob's, just removing the bits to build everything in, and use the system libraries for things like x264 instead.
As I say, it has been working fine for ages, and only just stopped. I'm not sure which update caused it, as I was away for a few days, and when I got back, several updates had occurred, so the whole lot got done as one (slackpkg+).
I have a feeling its something to do with the graphics rendering somewhere. I don't believe its H264 or ffmpeg, as mpv and ffplay play just fine, albeit at a higher cpu usage, I suspect. In any case, I rebuilt both H264 and ffmpeg using tweaked SBo scripts (as above) and it made no difference.
Not sure where to look next. Its certainly an odd one!
Yes, I have both x264 and x265, and have recompiled x264 (I was already running the latest version, and it has no dependencies) without success. In any case, if it was x264, I would have the same problem with MPV and ffplay, but I don't. Its only VLC (and Kaffeine, which depends on libVLC) that is affected.
As I say, I think its something in the graphics configuration that vlc doesn't like. MPV has a "gpu" option for video output, but vlc seems to use OpenGL. Maybe something to do with that? I've tried the other options, but they never did play nicely with the Pi.
Not sure this is helpful, but I ran across a similar problem with playing back video streams from a raspberry pi using vlc and found this on the raspberry pi website:
Quote:
Note
Recent versions of VLC seem to have problems with playback of H.264 streams. We recommend using ffplay for playback using the above commands until these issues have been resolved.
Accordingly, you may be running into the same problem with h.264 playback.
If this is all current and you're compiling, is everything compiled against the same glibc? Glibc versions have been changing in current.
Interesting this: I have VLC-3.0.18, and updated to current recently (Last RazPi image of Slarm64, w/ kernel-6.4.8 & glibc-2.37). Now VLC is acting up on some videos. Others play fine. I get the sound and a succession of frozen frames But I have vlc-3.0.18 on slackware64-15.0 in an x86-64 Box and the videos work fine. I can't try them on x86_64 current, because my liveslak has glibc-2.36 and current is compiled with glibc-2.37 . But the main slackware forum is awful quiet about vlc, so I presume it works.
Last edited by business_kid; 09-04-2023 at 07:27 AM.
I'm on slarm64 and just updated to the slarm64-current-aarch64-xfce-raspberry_pi_4-6.4.8-build-20230807.img, with glibc-2.37 & kernel-6.4.8.
FWIW, last time I updated Slarm64 was January 2023, and I grabbed a lot of archives in Febuary - like vlc, which has started acting up now that I've updated my system in the last week. That makes me think the problem isn't solely with vlc. I haven't updated vlc yet. I'm not likely to either, until all the problems go away. So I have those extra packages from early 2023, as well as the slackbuilds and source.
The one obvious package I did have and rolled back was x264, and that had no effect. So you can eliminate that from your enquiries. If anyone wants to try rolling other things back, PM me if you want stuff from 7/8 months back.
There is a good chance the addition of the lua package into slackware-current could be part of it. SBo has lua version 5.1.x and -current has lua 5.4.x. There is a thread about it in the x86 forum: https://www.linuxquestions.org/quest...on-4175728585/
It refers to mpv difficulties, but I see on SBo that lua is a dependency to building vlc. Maybe rebuild the entire vlc stack, including vlc to see if you can track the problem down? It's possible one of the other dependencies in that stack is the issue too.
I tried vlc-3.0.17.4, from 2022, and that acts up on my current. My vlc-3.0.18 from early this year worked fine, until I moved to the latest current. So it's a run-time dependency.
I'm an electronics hardware guy, no software dev. So here's a suggestion: Can someone go back through the ChangeLog.txt for current for about 6 months and see which vlc dependencies have been updated? I'm presuming Slackware Arm mirrors slackware64-x86_64-Current, as slarm64 does. I don't mean build-time dependencies, I mean run-time dependencies. There shouldn't be many, and that will provide a very short list of suspects.
OK, this is weird! I should have mentioned that slarm64 has been having the same issue for some time. Well today I did the slarm64 updates from the 4th September:
After these updates, kaffeine now plays hdtv perfectly (uses libvlc). However, vlc is still unable to play local h264 files. MPV plays local H264 files fine, but weirdly smplayer (using mpv) crashes!
Like slackwareaarch64, slarm64 has specific kernels for the Pi (currently 6.4.8), so it isn't the kernel causing the issues. One of the above updates has provided a partial solution - but which one?
If I were the betting type I'd put money on this one:
Code:
l/SDL2-2.28.3-aarch64-1.txz: Upgraded.
That's Simple DirectMedia Layer. That might be involved, all the rest shouldn't be.
There's also the question of whether all those Arm-specific patches to make stuff compile have bent/broken something that they shouldn't have, or even fixed something that should be broken.
Last edited by business_kid; 09-05-2023 at 02:29 PM.
Yes, SDL struck me as being a likely candidate. Lets see what happens when slackwareaarch64 catches up.
Its still only a partial solution, though. Perhaps recompiling vlc against the updated SDL will provide a complete fix. Might give that a try tomorrow.
Time is running out a bit for me at present. After Thursday, I'll be out of the country for a week or so and unable to experiment further. Hopefully, by the time I get back there'll be a solution...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
. But the main slackware forum is awful quiet about vlc, so I presume it works.
