slarm64This forum is for the discussion of slarm64.
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.
It appears they have solved it in the last day or two, but I applied the slarm64 updates from the 4th & 5th and they don't seem to have helped.
My VLC is 7/8 months old, and worked fine until the update. The vlc in your repo is vlc-3.0.17.4, compiled last November. I, however have 3.0.18 on disk which I got in February I reinstalled libx264 from 6 months ago - no change. I did even drop back to vlc-3.17.4, but that's the same. I can play most mkvs and avis without issue, I can play mp4s with mpv or with a browser.
As the thread shows, Slackwareaarch64 seems to have fixed it, more by accident than design it appears. I've installed your updates from 4th & 5th of this month (except the console based ones & kernel 6.1.51) but no change here.
EDIT: Sound is ok, but the logs (messages, syslog, dmesg) only show error number 19 (No such device) from some hifi bit of the sound SoC. The video plays either extremely slow (e.g. unwatchable tears on the 'Paramount' or 'Universal' logos) or leaves the screen black with nothing in the logs. I tried installing vlc on the sdcard image, installed libcaca & libx264, but then I ran out of ideas because I didn't know what it wanted.
Last edited by business_kid; 09-08-2023 at 04:18 AM.
At last I've got some diagnostics out of this with cvlc
Code:
VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)
[00000000292328b0] dummy interface: using the dummy interface module...
[0000007f3c88ce00] chain filter error: Too high level of recursion (3)
[0000007f3c88c6c0] main filter error: Failed to create video converter
[0000007f3c88ce00] chain filter error: Too high level of recursion (3)
[0000007f3c88c6c0] main filter error: Failed to create video converter
[SNIP REPEATS]
[0000007f3c88c6c0] main filter error: Failed to create video converter
[0000007f3c88ce00] chain filter error: Too high level of recursion (3)
[0000007f3c88c6c0] main filter error: Failed to create video converter
[0000007f3c88ce00] chain filter error: Too high level of recursion (3)
[0000007f3c88c6c0] main filter error: Failed to create video converter
[0000007f3c88ce00] chain filter error: Too high level of recursion (3)
[0000007f3c88c6c0] main filter error: Failed to create video converter
[0000007f3c88acd0] main filter error: Failed to create video converter
[0000007f3c0013f0] main vout display error: Failed to create video converter
[0000007f3c0013f0] main vout display error: Failed to adapt decoder format to display
[0000007f44045cb0] main video output error: video output creation failed
[0000007f5b53aef0] main decoder error: failed to create video output
Segmentation fault
bash-5.2$
The sound comes through without the video. This next video shows the title in bold at the bottom correctly. Then the sound plays, although the screen remains black. It's an mkv. I get the same errors exactly as above. But vlc doesn't segfault where cvlc does, and goes on
Code:
bash-5.2$ vlc Inside.Russia.Traitors.and.Heroes_BBC.Storyville.mkv
VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)
[000000001482d800] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[000000001491c680] qt interface error: Unable to load extensions module
[0000007f8c8308b0] chain filter error: Too high level of recursion (3)
[SNIP REPEATS]
[0000007f8c830200] main filter error: Failed to create video converter
[0000007f8c8308b0] chain filter error: Too high level of recursion (3)
[0000007f8c830200] main filter error: Failed to create video converter
[0000007f8c728900] main filter error: Failed to create video converter
[0000007f8c0044b0] main vout display error: Failed to create video converter
[0000007f8c0044b0] main vout display error: Failed to adapt decoder format to display
[0000007f24130c90] main video output error: video output creation failed
[0000007f34ce2e10] main decoder error: failed to create video output
Failed to open VDPAU backend libvdpau_vc4.so: cannot open shared object file: No such file or directory
[hevc @ 0x7f34cff730] Could not find ref with POC 28
[hevc @ 0x7f34d94070] Could not find ref with POC 42
[hevc @ 0x7f34d94070] Could not find ref with POC 44
[hevc @ 0x7f34d94070] Could not find ref with POC 50
[hevc @ 0x7f34cef850] Could not find ref with POC 62
[hevc @ 0x7f34cef850] Could not find ref with POC 64
[hevc @ 0x7f34cef850] Could not find ref with POC 70
[0000007f34ce2e10] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[0000007f34ce2e10] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
I get the "hevc @" errors followed by the "dropping frame" errors in 12s - a minute at a time. It seems to be continuous until I killed it.
The libvdpau_vc4.so isn't a thing. Nodody has it. But there's libvdpau_radeon & libvdpau_<this, that & the other>. vlc works without libvdpau_vc4.so.
Nearly every mp4 I have behaves slightly differently. Some make the bounding box for cvlc before they segfault. Dmesg gives this line sometimes
That mode is supported. Now I can get out of this in about 20 minutes by restoring a backup, but it just happens that what we're watching now isn't affected. My last update was the (Jan 2023?) RazPi image with the 6.2.0 kernel. That's clear of problems. But it's glibc-2.36.
Installed the updates up to 9/09/2023 from slackware.uk.
It's a slight improvement, but as there's such variation between the test files, it's difficult to summarize. The new Mesa-23.1.7(?) is in there.
Slackware.uk have ftp, so I was able to mirror the slarm64-current/slarm64/ directory, and then run upgradepkg on it, installing the new ones. ffplay & mpv both play mp4s well, leaving vlc alone with the error, and cvlc with the segfault. Now some of the mp4s render a picture every three seconds or so. The video errors in dmesg have disappeared. It also appears the dmesg differs depending on whether you read it from a tty or an X terminal - very strange.
I found that forcing vlc to use the "opengl" video out got it working again. Strangely, once I'd done that, I could put it back in "automatic" and it still worked! No, I don't understand it either! Kaffeine - which uses libvlc - also plays local files fine, but has now stopped talking to my tv-hat! Not had that problem before, and it still works OK in Slackwareaarch64, so its not hardware.
Relevant bit from dmesg:
Code:
dmesg | dmesg | grep cxd2880
[ 3.573861] failing symbol_get of non-GPLONLY symbol cxd2880_attach.
[ 3.573910] DVB: Unable to find symbol cxd2880_attach()
[ 3.573926] cxd2880_spi: cxd2880_spi_probe: cxd2880_attach failed
cxd2880 is the dvb-t adapter type. It was working, and now it isn't! No idea why.....!
I found that forcing vlc to use the "opengl" video out got it working again. Strangely, once I'd done that, I could put it back in "automatic" and it still worked! No, I don't understand it either! Kaffeine - which uses libvlc - also plays local files fine, but has now stopped talking to my tv-hat! Not had that problem before, and it still works OK in Slackwareaarch64, so its not hardware.
Relevant bit from dmesg:
Code:
dmesg | dmesg | grep cxd2880
[ 3.573861] failing symbol_get of non-GPLONLY symbol cxd2880_attach.
[ 3.573910] DVB: Unable to find symbol cxd2880_attach()
[ 3.573926] cxd2880_spi: cxd2880_spi_probe: cxd2880_attach failed
cxd2880 is the dvb-t adapter type. It was working, and now it isn't! No idea why.....!
--
Pete
It narrows the problem down for you guys a good bit if the updates from 20230910 alone are what fixed it. I only use XFCE, but I know the libs in kde fix some random compatibility issues. I ended up having to install kde/ on my x86_64 box.
I also ran into an issue in that I couldn't set a luser password, I'm settling this system on sdcard before imposing it on my SSD to avoid having to dig deep fixing some issue. It's much easier to just start from square one. You're welcome to your tv hat. I have all the English stations nearby, which beckon. But if I had the English channels, I'd spend more time searching out something to watch than I would watching them. And there's the matter of a GBP160 tv license required, geolocation issues, etc.
With a kosher (unprivileged) user, the vlc binary works. And I can run the latest palemoon-32.3.0, therefore the latest glibc. Therefore, I am declaring this problem teetotally sorted.
Last edited by business_kid; 09-19-2023 at 08:32 AM.
Resurrecting an old thread here - and I will also update over on the slackware arm forum.....
VLC has been broken for quite a while on all the slackware arm distros. Its been weird because sometimes an update would get it working again, and then another one would break it again!
I've recently built vlc-3.0.20 and managed to get it working fine on both slarm64-current and slackwareaarch64-current. The trick is to select XVideo out (XCB) rather than opengl. By doing this I can play 1080 videos with only around 35% cpu load on all 4 cores.
However, I still cannot use kaffeine, which uses libvlc. There are two reasons for this. One is that, although kaffeine allows passing arguments to libvlc, according to the developers, libvlc won't accept any arguments passed to it! They suggested stopping libvlc from loading the gl plugin, but have offered no advice on how to do this! VLC's "configure --help" offers no options for suppressing opengl. It appears to be always built by default!
More relevant to slarm64 is that all of the currently available 6.x.x series kernels (6.5.2 at the time of writing) suffer from the "nvidia bug" which stops my TV-hat being recognised - as detailed here: https://www.linuxquestions.org/quest...ls-4175729154/
Any chance of a more recent 6.X.X kernel for us Pi users?
VLC has been broken for quite a while on all the slackware arm distros. Its been weird because sometimes an update would get it working again, and then another one would break it again!
To me, it sounds like one of the Arm-specific Patches is breaking it. It's fine on x86_64. That narrows the field considerably. Of course, I'm a hardware guy, software isn't my thing.
Quote:
Originally Posted by pchristy
I've recently built vlc-3.0.20 and managed to get it working fine on both slarm64-current and slackwareaarch64-current. The trick is to select XVideo out (XCB) rather than opengl. By doing this I can play 1080 videos with only around 35% cpu load on all 4 cores.
How do you do that? At compile time?
Last edited by business_kid; 11-07-2023 at 10:20 AM.
Agreed its a problem specific to the Pi. My money is on the interaction between the graphics drivers and OpenGL.
To force VLC to use XVideo is simple: Tools>Preferences>Video, and then from the drop-down select "Xvideo output (XCB)" instead of OpenGL or automatic.
Passing a similar command line vout to libvlc from kaffeine doesn't work! There doesn't seem to be a forum anywhere to contact the kaffeine developers, and there hasn't been a release in 4 years! However, it is still being updated on github, the most recent updates having been in the last few weeks. I'm going to try and contact the developers there...
I'm frustrated with Pi Graphics, and Arm graphics generally.
Raspberry pi OS haws workable 1024x768 at low cpu overhead. The sales promise was "2x4k@60Hz outputs" which it clearly doesn't do, even 4 years later. The sales Promise for the Pi 5 gpu spec is exactly the same. And they have a closed source driver in rpi OS which the community doesn't have.
The Arm Mali GPUs have no decent linux driver either, AFAICT. I'm disappointed with that, seeing as they have so much of a stake in OSS. Otherwise, I'd get an Orange Pi 5 with the RK3588 SoC. In fact you have to go to Solid Run's mini-server which has a pcie slot. That will take an AMD graphics card.
Yes, I too am disappointed with the poor graphics performance. Even PiOS struggles with 1920x1080 video! However, Librelec/Kodi plays 1080 without breaking into a sweat, and I can even play 4K smoothly on it with my Pi400, without any issues at all. It IS possible!
I would love to know how Libreelec/Kodi manage it!
As I understand it, the original issue was that Broadcom wanted money for the drivers. Clearly someone has managed to reverse engineer it - and with a supposedly open-source distribution. I'm amazed no-one else has picked up on it. I would give it a try myself, but it is well above my limited abilities! I peaked with 6502 machine code over 40 years ago.....!
The Raspberry Pi Foundation have rewritten their video drivers and FFMpeg support to follow the common V4L2 frameworks. As their goal is to upstream all driver and player-app changes, allowing them to be included and used with all Linux distros, the rewrites do not include the custom HEVC optimisations that would never be accepted.
What I don't see is "acceleration." The place for their custom optimisations would surely be a Mesa driver. But they are not bothered. Vroadcom are very restrictive with linux support. Hardware Engineering types are totally paranoid about having their ideas stolen. They never get it that if their ideas are any good, they'll have to ram them down someone's throat anyhow.
It is three years old now, but involves one of Raspberry's software engineers answering questions about acceleration, and he mentions Libreelec. To me, one of the interesting things he says is:
Quote:
You are aware that the 3D/OpenGL system has changed completely on the Pi4? We have a newer VC6 GPU and that is driven by the standard Linux MESA driver, not the firmware (so we are moving towards a more open and standard system).
It has seemed to me for a while that the issues I've been having have been related to MESA/OpenGL, so I wonder if they have implemented something special in that, that hasn't snuck through to our systems yet? Or hasn't been updated recently?
I went into the /usr/lib64/vlc/plugins/video_output folder, and moved everything that had libgl in the filename to a temporary location elsewhere! (12 files altogether)
Now the dropdown folder in VLC no longer offers any GL options, and can be reset to automatic. Also Kaffeine now plays HD and SD TV, and 1080 files without any further issue. Haven't tried any HEVC (X265) stuff, but I wouldn't expect that to work anyway at present. The main thing is that I can now watch and record HD TV again! (Actually, I could record it before! I just couldn't watch it or play it back on the Pi...)
Next step might be to get X265 working, but that maybe beyond my abilities!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
I reinstalled libx264 from 6 months ago - no change. I did even drop back to vlc-3.17.4, but that's the same. I can play most mkvs and avis without issue, I can play mp4s with mpv or with a browser.
