[Slackbuilds-users] vlc slackbuild

[Tim Dickson]

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'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.
>
>
>> 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.)
by that I mean I don't enable them in the options, so that I don't have 
to "update" stock slackware packages
> I just tried (with both my "normal" vlc and the wayland enabled vlc
> running in a VM) the box.mp4 and cup.mp4 that come in
> /usr/doc/opencv-4.0.1/html (although not in opencv-legacy) and both play
> fine, apart from a bad/noisy audio track in cup.mp4.
>
> Both my bare metal and VM systems contain libva and libva-intel-driver
> packages but I don't believe they have any effect since the bare metal
> system runs the nvidia binary blob for a physical nvidia card while the
> VM (qemu-kvm) has it's own virtual video output.
>
> When you say you build with everything "except libva and
> libva-intel-driver" do you mean they are not installed? If you don't
> have the libva* packages, which are part of a full Slackware-14.2
> installation, I wonder if you are building/running without some other
> standard packages which may have impacted on your builds of vlc and it's
> many dependencies?
>
> chris
I start with a full (including kdei) slackware 14.2 install, then 
upgradepkg/installpkg everything in the latest patches/packages/*.t?z
then I update the kernel taken from the same place (and source).
I build (and install) all the sbo packages on  a qemu vm (using sbopkg), 
and then install them to test on a real pc (with amd apu)
( output of
  ls /var/log/packages/libva*
is
/var/log/packages/libva-1.6.2-x86_64-1
/var/log/packages/libva-intel-driver-1.6.2-x86_64-1
)
I  had to modify fluidsynth slackbuild adding -lpthread to 
-DCMAKE_EXE_LINKER_FLAGS and also to -DCMAKE_SHARED_LINKER_FLAGS
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.

regards, Tim