Videos with hevc encoding work fine on system, but I self-compiled mplayer back in November (and I have ffmpeg 2.1.5 from SBo compiled in March). Granted, I only have 720p encodings, but they play perfectly fine (no noticeable stuttering) on my super old system (7 year old dual core with an HD3870). I'm not sure how bad 1080p would play, because on super high quality bitrates, even h264 will crap out on my system without vdpau.

But this is using smplayer, which handles most, if not all, of the mplayer options. Here's the command line that it used when I played an h265 file (if it helps at all).

Since it was suggested by bassmadrigal, I decided to try it out. For video playback, it is much easier to control, and I especially like the fact that it remembers where I left off on watching videos. For music playback, though, I am less satisfied; I much prefer VLC's interface, and will continue to use that. It's kind of a split strategy, but it's part of the beauty of open source software; since I don't have to pay for it, all I have to pay is time (to compile), and that I have plenty of.

Regards,

Matt

Hi.

The world of POSIX/UNIX conformance is not as black & white as the VLC maintainers seem to think.

First, POSIX.1-2008 only requires the provision of c99, lex, and yacc for systems claiming conformance to the C-Language Development
Utilities option (POSIX2_C_DEV) . Otherwise-conformant systems that don't claim conformance to that specific option have discretion
as to the provision of those three utilities.

The more important point, however, is that most *nix systems (including Linux), and I use the term informally, find themselves at varying
levels of POSIX and/or UNIX spec compliance.

That's the boring part. Now, on to the good stuff...

I've put together a c99 utility (wrapper to gcc) that'll help users who come across finicky programs that require it. To set it up on your
system:

1. Get c99
   
   # wget http://sf.net/projects/mancha/files/misc/c99
   
   
2. Move and set proper perms
   
   # mv c99 /usr/bin
   # chmod 755 /usr/bin/c99

--mancha

SHA384 (c99) = 2d191f93dd1a4f7dcad8001540408b4709f99cd2bf36a1a2ca61a4469a7e30266446866881825825e77a51668a7abf79

4 members found this post helpful.

Thanks for the info, mancha. I've done as you've posted; I personally haven't come across this particular problem, but it's better to have it and not need it, than the other way around.

chris.willing -> Yep, that did the trick, thanks! I tried something like this but probably fumbled somewhere with the syntax.
55020 -> Thanks for the bother. I didn't give the trac ticket, well, because there wasn't much to get from there, apart starting a discussion about the way it was handled by the VLC devs. The later worked well apparently. :-)

I checked with Pat when I returned from holiday yesterday, and discussed this thread. He took immediate action. The scheduled gcc update for Slackware-current includes c99 and c89 wrapper scripts. Pat's packages are already built and I am compiling the gcc-multilib packages at the moment.

2 members found this post helpful.

Cool! I'll update as soon as the packages are available and let you know how it goes on that particular problem.
Thanks!

Thanks, Eric. This should alleviate the problem, at least that can be fixed technically.

OK.

I performed a quick check and it turns out other Linux distribs ship a c89 wrapper (ISO/IEC 9899:1990 standard) in addition to a
c99 wrapper. So, I developed two more gcc wrappers to accompany my earlier c99: c89 and c11.

Note: I've also posted a new c99 wrapper that includes two changes: a) now recognizes the deprecated c9x and iso9899:199x
standard labels, and b) uses -pedantic rather than -pedantic-errors. As before, download whichever you need/want, move
them to /usr/bin, and change their perms to 755.

Hashes are:

Enjoy.

--mancha

1 members found this post helpful.

Just to report that the latest gcc packages that contain the c99 script indeed allow for proper VLC compilation.

He's of the rigid type indeed :-). But his information is very often on target though, and he answers many threads on the VLC forums.
So I guess he keeps his answers short.

I'm curious as to your preferences in UI, if it is just the locations of menuitems or missing/unfamiliar options. Are collections a concern? Does sound tweaking enter into it at all?

I'm asking this because to me performance and configurability are the high order bits. Amarok looks slick and does pickup content and organize nicely but does too much I don't care much about and not enough of my major concerns. For music playback in Linux I have been using Aqualung for several years even though it's menu style isn't my favorite but it is ultra simple (though by no means slick or modern looking) and has superb controls and most importantly to me can employ LADSPA (and I'm hoping VST plugns before long) and works exceptionally well with Jack.

LADSPA is hugely important to me because I require more than a Bass and Treble control and prefer a serious Graphic Equalizer, specifically a parametric so I can dial in exact frequency ranges to suit the room, speakers, and even the recorded environment itself. I want to always hear each instrument as clearly as possible as was intended by the recording engineer and my ears. The "Tube Warmth" plugin is nice for harsh sounding CDs/DVDs or nasty mp3s . Granted I am an audio fanatic and also use an Alsa addon for a persistent, system-wide 10 band graqphic EQ.

Anyway if sonic performance is near the top for you a well, you may seriously enjoy playing with plugins with Aqualung. You can get an idea of UI from the skins page which shows the UI and some of the configuration layouts, here at

Aqualung Skins . As I said more of a sow's ear than a silk purse in form but the function is superb and conducive to eargasms. :P

My reasons for using VLC are: I much prefer all of my playlist to be listed in a scroll-able window, and the search bar at the top allows me to get at any song just by typing in song name, artist name, or even genre.

I'm not much of an audiophile, so using LADSPA isn't imperative (other than using USB Audio, which, I've heard, is much superior to sound from a sound card; I could be wrong on this point, but I am satisfied with the sound coming out of the headset, so I'm not complaining).

You're right that Aqualung isn't slick-looking, and its apparent inability to import entire directories is a dealbreaker for me. I found an old SlackBuild for aqualung, and edited it to exclude the patch. It appeared to compile successfully, but without LADSPA plugin support. Is there a configure option I need to add to make this happen?

As for Jack, I'm reluctant to make invasive changes to my sound system without good reason to do so. I'm aware of AlienBOB's post about enabling Jack audio in Slackware, BTW.

If you can give me solutions for the importing of entire directories and the inclusion of LADSPA plugin support, I'm more than willing to give Aqualung another go. Cheers!

Regards,

Matt

Oh I agree he is a smart guy, and without him VLC would not be where it is today. But smart persons can still be social imbeciles.

Yes there is a config option for "--enable LADSPA". I don't think you would find Jack invasive but only helpful at taking disparate devices and/or applications and connecting them in desirable, managed ways. It's basically a switchboard, entirely configurable for any job or user since it does very little on it's own and behind your back. It hands the power to the user.

Regarding Playlists perhaps it is due to an older version but from the most recent Aqualung User Manual

While in general SlackPacks have made me lazy, Aqualung is one of those apps both important enough and easy enough for me to install the latest from raw source. I've done this several times (on several machines) and found it to be rather effortless... apparently well-written with extremely few hard dependencies not already present in Slack.

I found this thread first by noticing the trac issue tracker where the VLC developers
treat rvdboom like garbage - which makes me wonder about VLC in general.

Anyway - I am currently on a non-slackware system and VLC refused to compile.

The error was the same as rvdboom reported.

I believe I removed some old GCC components at /usr/bin; my real GCC was
at /home/Programs/Gcc/9.2.0 and is symlinked into the correct locations.

Do note that, just like rvdboom, I can compile everything fine - just the
VLC script being broken. The VLC should fix their crap code rather than
insult people who report bugs onto that broken trac interface (MS github,
although owned and controlled by Microsoft, has a MUCH better, simpler
interface than this awful crap that is trac).

For my situation, setting the environment variable

BUILDCC: /usr/bin/gcc

worked. Yes, exactly one (!) export setting. So the VLC devs screaming
about how broken slackware is should stop whining like crybabies and
fix their broken GNU configure macros. Because I only had to explicitely
tell GNU configure where GCC is. I have no idea why VLC fails and other
programs work, but in my case I think it is somewhat related to my
current toolchain not being totally correct; it is probably a mix of
old and new gcc/binutils stuff. But even with that in mind, a single
export, and VLC compiles fine ... hmmmmmmmm. I guess we now know where
the noobs are - and the noobs are NOT rvdboom, me, or anyone else
running into that problem. The VLC folks really noobed it up.

I write the above down in particular because it was a solution that
worked for me - hopefully if others are in a similar situation they
may be able to solve this. In the long run I recommend to the VLC
devs to become better - and perhaps consider moving to cmake or
meson/ninja. The latter two are not perfect, I know that too, but
they seem to be better than the GNU configure stack, and have more
momentum as well. I mean GNU configure still tends to use libtool ...
do we have to say anything more about the quality of a shell script
(mostly) like libtool?