[Slackbuilds-users] vlc slackbuild

Christoph Willing chris.willing at linux.com
Mon Feb 25 12:55:19 UTC 2019

On 25/2/19 9:32 pm, Tim Dickson via SlackBuilds-users wrote:
> On 25/02/2019 02:47, Christoph Willing wrote:
>> On 24/2/19 9:50 pm, Tim Dickson via SlackBuilds-users wrote:
>>> On 24/02/2019 01:26, Christoph Willing wrote:
>>>> On 24/2/19 10:06 am, Tim Dickson via SlackBuilds-users wrote:
>>>>> On 23/02/2019 03:17, Christoph Willing wrote:
>>>>>> On 23/2/19 3:51 am, Tim Dickson via SlackBuilds-users wrote:
>>>>>>> On 22/02/2019 12:51, Christoph Willing wrote:
>>>>>>>> On 22/2/19 8:33 pm, Tim Dickson via SlackBuilds-users wrote:
>>>>>>>>> vlc was built with the options OPENCV=yes WAYLAND=yes
>>>>>>>>> I can provide all the build options chosen for all the deps if it
>>>>>>>>> would
>>>>>>>>> help.
>>>>>>>> I admit that I don't test that particular option combination very
>>>>>>>> often.
>>>>>>>> I just rebuilt vlc with OPENCV=yes (using opencv-legacy) and a
>>>>>>>> quick
>>>>>>>> test of the resulting vlc was fine.
>>>>>>>> However the wayland option is quite time consuming to test since it
>>>>>>>> requires qt5 to have been (re)built with wayland, wayland-egl &
>>>>>>>> wayland-protocols already installed. It's now late enough here
>>>>>>>> that it
>>>>>>>> will be an overnight job to rebuild qt5 and then vlc.
>>>>>>>> In the meantime, could you build & test vlc without wayland
>>>>>>>> support?
>>>>>>>> Success there would indicate that wayland support is the problem.
>>>>>>>> Then
>>>>>>>> we'd have to figure out a possible fix or just not support that
>>>>>>>> option
>>>>>>>> any more.
>>>>>>>> chris
> I did notice that using installpkg of the vlc with different build
> options instead of removepkg then installpkg when recompiling with, then
> without opencv-legacy caused an issue in that opencv files were left in
> /usr/lib64/vlc/plugins which continued to cause the problem. I had to do
> a removepkg, then clean (rm -r) that directory, before installpkg again
> in order to get vlc to start.
>>>>>>> I've now also tried the other way around, enable wayland and disable
>>>>>>> opencv (legacy) and it now runs without seg-faulting, which is the
>>>>>>> opposite result of your test!. I'm open to more suggestions,
>>>>>>> although at
>>>>>>> least it runs now,
>>>>>> I finished building wayland enabled (but otherwise standard) qt5 and
>>>>>> vlc
>>>>>> in a stock 14.2 x86_64 VM with opencv-legacy. It runs normally - no
>>>>>> segfault and I can play a test video with it.
>>>>>> When run it from a terminal, the only new output is:
>>>>>>        libEGL warning: DRI2: failed to authenticate
>>>>>> but it has no apparent effect to the running vlc.
>>>>>> Since you're segfault-free after removing opencv-legacy, I guess
>>>>>> that's
>>>>>> the place to look for a cause - perhaps some exotic option it's built
>>>>>> with?
>>>>> (looking at opencv-legacy, I built it will all options, including
>>>>> ffmpeg
>>>>> which is a recursive dependency via frie0r)
>>>> Maybe that is an issue - I never attempt to resolve that recursion. I
>>>> choose to build opencv with ffmpeg support since I can accept that may
>>>> be useful. I don't see how ffmpeg could benefit (for me) from opencv
>>>> support so I don't bother with that.
>> To test whether the recursive dependency of ffmpeg is an issue here, I
>> rebuilt the relevant packages several times as follows, including tests
>> of (rebuilt) vlc shown in square brackets:
>> ffmpeg        (no build opts)
>> opencv-legacy (no build opts)
>> frei0r
>> ffmpeg        FREI0R=yes OPENCV=yes
>> opencv-legacy CVFFMPEG=yes
>> frei0r
>> [ vlc         OPENCV=yes WAYLAND=yes ]
>> ffmpeg        FREI0R=yes OPENCV=yes
>> [ vlc         OPENCV=yes WAYLAND=yes ]
>> opencv-legacy CVFFMPEG=yes
>> [ vlc         OPENCV=yes WAYLAND=yes ]
>> At all test points, I couldn't find any problem with vlc, including
>> playing of mp4 files.
> helpful, thanks.
> I did..
> create ffmpeg with no vars
> create quicktime, mjpegtools, transcode, vid.stab, opencv-legacy, frei0r
> ffmpeg with all vars ( ASS=yes BS2B=yes CELT=yes CHROMAPRINT=yes
> DC1394=yes EBUR128=yes FDK_AAC=yes FLITE=yes FREI0R=yes GME=yes
>  GSM=yes IEC61883=yes ILBC=yes LADSPA=yes LAME=yes MODPLUG=yes
>  X264=yes X265=yes XVID=yes ZMQ=yes ZVBI=yes )
> recreate transcode and vid.stab
> ffmpeg
> recreate chromaprint
> ffmpeg

In the VM I'm using to try to recreate your issue, I explicitly enabled
only OPENCV & FREI0R - trying to keep things as simple as possible.
However most options seem to be autodetected anyway e.g. h264 which you
confirm a bit further down. Accordingly there is very little difference
in our configuration logs (see below).

On my bare metal, I do explicitly enable many options:
ENVOPTS="ASS=yes BLURAY=yes CELT=yes DC1394=yes DECKLINK=yes FAAC=yes
GSM=yes IEC61883=yes ILBC=yes LADSPA=yes LAME=yes MODPLUG=yes NVENC=yes
SCHROEDINGER=yes SPEEX=yes TWOLAME=yes VPX=yes X264=yes X265=yes
ZVBI=yes XVID=yes

>>>>> Although without opencv , vlc starts up ok, when I try to play an mp4
>>>>> video file i get
>>>>> codec not supported
>>>>> VLC could not decode the format "h264" (H264 -MPEG-4 AVC (part 10))
>>>>> despite the fact that vlc and ffmpeg have been compiled with
>>>>> everything
>>>>> (all required and optional dependencies) except libva and
>>>>> libva-intel-driver
>>>>> (as I use amd apu's.)
>> I think it's worth looking at your vlc build log, looking for references
>> to h264. In my log, the configuration stage says:
>> checking for x264 >= 0.148... yes
>> checking for x264 >= 0.153... no
>> Does yours have something like that?
> yes, see attached

I'm running out of ideas as to why you're unable to play mp4 files (let
alone your original segfaulting problem). Could you extract the two mp4
examples from the opencv-4.0.1.tar.gz tarball and try those please?
They're at:


Then we'll know we're testing the same thing.

>> Feel free to attach your log (just up until configuration stage is done)
> see attached section of log
>> ....
>> OK, thanks for clearing that up. Do you ever use slapt-get or slackpkg
>> to verify that all the packages are up to date? Manual updates are all
>> very good but, given the number of patches involved, error prone.
> no, but I do use the feature in sbopkg that does the same sort of thing.
> the only things at the moment I have on the "real" machine and not the
> vm is eric's libreoffice packages, flashplayer plugin and chromium
> browser with plugins.
> (and I have qemu and aquemu on the vm, and not the "real" machine)
>>> I  had to modify fluidsynth slackbuild adding -lpthread to
>>> in order for it to compile/link (thanks B. Watson)
>>> and avahi user and group were created on both vm and real machine as per
>>> the avahi readme.
>> Good that it helps but I wonder why you need this addition? I just
>> rebuilt fluidsynth without it. The fact that you need it is somewhat
>> concerning - it may point to some problem with your system that, in
>> turn, is affecting your vlc build ...
> it is because pkg-config doesn't add the -lpthread entry it needs to
> when using jack2. (whereas jack-audio-connection-kit does have the
> needed entry)
> i don't know if it effects any other builds, but i does effect
> fluidsynth built with jack2 instead of jack-audio-connection-kit, and as
> jack2 is needed for some other deps, and is supposed to be plug in
> compatible, that is what I used.

OK the jack2 vs jack-audio-connection-kit shows up in the diff below but
it's unlikely (I think) to be the cause of your vlc issues.

Here is a diff of the configuration section of our log files. No clues
unfortunately - there's not much difference between them and nothing
that obviously points to segfault or mp4 difficulties..

diff chris.log tim.log
< checking for opencv > 2.0... yes
< checking gme/gme.h usability... no
< checking gme/gme.h presence... no
< checking for gme/gme.h... no
> checking gme/gme.h usability... yes
> checking gme/gme.h presence... yes
> checking for gme/gme.h... yes
> checking for gme_identify_header in -lgme... yes
< checking for wayland-client >= 1.5.91... yes
< checking for the Wayland protocols... //usr/share/wayland-protocols
< checking for the Wayland scanner... /usr/bin/wayland-scanner
< checking for wayland-egl... yes
< checking for jack >= 1.9.7... no
< configure: WARNING: Requested 'jack >= 1.9.7' but version of jack is
0.125.0, trying jack1 instead
< checking for jack >= 0.120.1 jack < 1.0... yes
> checking for jack >= 1.9.7... yes

More information about the SlackBuilds-users mailing list