My thoughts on Slackware, life and everything

Tag: ffmpeg (Page 1 of 2)

Some recent package updates: chromium (-ungoogled), ffmpeg, handbrake, pipewire-jack

Chromium, regular and un-googled.

Google is speeding up its Chromium release cycle. Let’s see if I can keep up since I also build the -ungoogled variant. The latest update is 116.0.5845.140 and addresses a vulnerability.
You can now upgrade to my latest chromium and chromium-ungoogled packages. The updated Slackware 15.0 and -current packages both for chromium and chromium-ungoogled are available in my repository and its mirrors (like my own US server and the UK mirror).

FFmpeg.

A recent upgrade of Vulkan in slackware-current prompted a rebuild of the ffmpeg 5.1.3 distro package, and for the same reason I had to recompile my enhanced ffmpeg package for -current. I used the opportunity to add an embedded version of SVT-AV1, an open source AV1 video encoder originally developed by Intel in collaboration with Netflix and later adopted by the Alliance for Open Media. My ffmpeg package already contains an AV1 decoder: the dav1d library, but now you can have a go at creating your own video in AV1 format.
Get ffmpeg-5.1.3 for -current here (unrestricted distribution) or here (this version can encode AAC audio and hence restricted to distribution outside the US).

Handbrake.

The version of this package targeting slackware-current also needed a recompile due to the Vulkan update in -current and here I used the opportunity to apply a minor version upgrade.
Get handbrake-1.6.1 here (unrestricted distribution) or here (this version can encode AAC audio and hence restricted to distribution outside the US).

Pipewire-jack.

In slackware-current, pipewire is a moving target. I know that a lot of people have switched from using pulseaudio and jack to just pipewire with varying levels of success. I keep offering the Jack Audio Connection Kit support libraries for pipewire which are not present in the Slackware pipewire package, simply because Pat compiles pipewire without jack installed.
Note: my pipewire-jack package is not replacing Slackware’s pipewire! It’s an add-on which depends on my jack2 package being installed as well. It’s quite similar in purpose to my pulseaudio-jack package which aims to add support for Jack in pulseaudio.
Get pipewire-jack-0.3.79 here.

Enjoy the weekend! Eric

VLC 3.0.18 packages for Slackware 15.0 and -current

largeVLCI have uploaded fresh packages for VLC 3.0.18, targeting Slackware 15.0 and -current.
I realized that it was already nine months ago that I did the last refresh of this mediaplayer package. The prior update also took a long time, 11 months to be precise. There’s not much exciting news about VLC 3.x to report about these days. The developers focus on version 4 of the VLC mediaplayer. The wait for that code to surface as a stable release has been ongoing for several years now. It looks like 4.0.0 is in “beta” but don’t hold your horses.

Apart from the version bump of VLC, I have also updated some of the vlc packages’ internal libraries: bluray, dav1d, ffmpeg, glew, libva, speex, upnp, vdpau, vlx and x265.
I did not consider the Alliance for Open Media’s aom codec yet; aom is a codec for the open and royalty-free AV1 video format, but my package already uses dav1d as an AV1 decoder. If someone needs VLC to be able to encode AV1 video through aom, let me know.

A note about dependencies for the new package:

My Slackware packages for VLC are mostly self-contained with all of the supporting libraries compiled into the package. This makes for a minimal dependency on external libraries/packages; a full installation of Slackware covers it all.
Let’s explicitly mention all those libraries that are statically compiled into my vlc package:

  • ffmpeg of course
  • audio codecs are provided by a52dec, vo-amrwbenc, opencore-amr, libdca, fluidsynth, gsm, lame, libmpcdec, opus, libshout, speex, speexdsp,  twolame
  • video codecs are provided by dav1d, libdvbpsi, libebml, libmatroska, libmpeg2, libvpx, theora, x626, x264, x265
  • subtitle and text rendering: libass, libkate, libtiger, srt
  • extension interpreter language: lua
  • digital media input: libdv, libbluray, libcddb, libcdio, libdvdnav, libdvdread, libdvdcss (only in the restricted package), libavc1394, libdc1394, libraw1394
  • visualisation: goom, projectM
  • file access and streaming: asdcplib, libdsm, libssh2, libupnp, live555, microdns, protobuf-cpp
  • miscellaneous: fribidi, glew, libva, libvdpau, pcre2, taglib

You’ll notice that I statically compile several libraries into VLC that are also present in regular Slackware (ffmpeg, lame, speex, theora, libvpx and more) but other libraries that are also present in Slackware (mpg123, openjpeg etc) are not included statically. I made an educated guess about the risk of breakage of my vlc package due to incompatible library updates in a Slackware release, and then I added all libraries statically that made me feel safer with regard to robustness of the resulting package. And of course, every library that I consider as mandatory for VLC that is not part of Slackware, is also added to my package statically.

A note on compiling:

When you want to compile VLC 3 yourself, be sure to install java11 and apache-ant or your build will fail.

Where to find the new VLC packages:

Rsync access is offered by the mirror servers.
The patent-safe packages are found at rsync://slackware.nl/mirrors/people/alien/slackbuilds/vlc/ and rsync://us.slackware.nl/mirrors/people/alien/slackbuilds/vlc/ .
The restricted versions that support AAC encoding and encrypted DVD playback are available from rsync://slackware.nl/mirrors/people/alien/restricted_slackbuilds/vlc/

For BluRay support, read a previous article for hints about the aacs keys that you’ll need.

Enjoy! Eric

I finally updated my avidemux package

I have an avidemux package in my (restricted) repository.
But… it had not been refreshed since Slackware 14.0 (8 years old now) and its binaries stopped working on Slackware long ago. Looking back at the packaging work I did today, I guess the thing that kept me from updating that Avidemux package was the numerous dependencies that also needed an update (they all were stuck at an old Slackware 14.0 release).

In the midst of a full week of holidays and waiting for my rye/honey sourdough bread dough to ferment, I had plenty time to devote to the creation of a fresh package for  Avidemux 2.8.0. This was recently released; yesterday actually!
And not just avidemux needed some work on its SlackBuild script; I needed to update ageing scripts for aften, faac, faad2, libdca, libfdk-aac, opencore-amr, x264 and xvidcore, and added a x265 package before I could compile avidemux with full support for codecs and plugins.

Based on the imminent (fingers crossed) release of Slackware 15.0 according to Patrick himself, I decided to create these packages only for Slackware-current (soon to become 15.0). I also cleaned out ancient versions of all these packages. They are now removed for Slackware 14.1 and older.
Note that faac and libfdk-aac just like avidemux contain patent-encumbered software (the AAC encoder) and due to that circumstance  the three packages are banished to my ‘restricted repository‘ which is hosted outside the US of A so that the patent trolls won’t bother Pat.

Let me cue you in about Avidemux in case you are not familiar with the program.
It’s a video editor supporting many video formats thanks to the built-in ffmpeg libraries and many plugins. It allows for a decent level of automation through tasks and scripts, and it has a command-line interface next to its Qt5-based graphical user interface.

Some of the 2.8.0 release highlights: Avidemux is now able to convert HDR video to SDR with tone mapping using a variety of methods. The FFV1 encoder has been added again. TrueHD audio tracks can be decoded and are supported for Matroska containers. The internal ffmpeg libraries are the latest 4.4.1 version. It integrates better with pulseaudio in terms of volume adjustments.

In case you are interested in some comparisons between the functionality of Avidemux and its competitors, here are some pointers. In terms of video conversion capability it compares to Handbrake (also in my repository), see here: https://en.wikipedia.org/wiki/Comparison_of_video_converters. When you look at its video cutting and edting qualities on the other hand, Avidemux is better compared with Kdenlive which is included in Slackware as part of KDE Plasma5: https://en.wikipedia.org/wiki/Comparison_of_video_editing_software

FYI… my sourdough bread is out of the oven, and it’s smelling great!

VideoLAN releases VLC 3.0.7

largeVLCThe new 3.0.7 release for the VideoLAN multimedia player VLC was tagged in git almost two weeks ago but it took until today to find official tarballs on their web site. By the looks of the git log I can only assume that the VideoLAN developers needed to fix some annoying post-release bugs first.
The ChangeLog documents that the focus of the developers is mostly on the Android, MacOS and Windows platforms, presumably because that is where most of the issues are found? Also – through sponsoring by the European Commission’s EU-FOSSA2 program – more than 35 security bugs were fixed.
So I built new ‘vlc‘ packages for Slackware 14.2 and -current yesterday and uploaded them to my repository. Between the previous 3.0.6 and this 3.0.7 release I u
pdated some of the packages’ internal libraries: bluray, dav1d, dvdnav, ebml, matroska. If you want to know what you can expect from the VLC 3.x releases (as opposed to the 2.x releases which took way too many years to get obsoleted) you can read this older article on my blog.

A note about dependencies for the new package:

My Slackware packages for VLC are mostly self-contained with all of the supporting libraries compiled into the package. This makes for a minimal dependency on external libraries/packages. But there are some caveats with the new release: most importantly, its interface has switched from Qt4 to Qt5.
While Slackware contains a ‘qt4’ package, it does not contain ‘qt5’ and therefore, the vlc-3.x package introduces some new external dependencies, all related to the Qt5 GUI: SDL_sound, OpenAL, libxkbcommon, qt5. Hopefully Qt5 will get added to Slackware-current sometime in the future.
On Slackware 14.2, two more packages are needed – they have already been incorporated into Slackware-current: libinput and libwacom .

A note on compiling:

When you want to compile VLC 3 yourself, be sure to install java8 and apache-ant or your build will fail.
If you are running Slackware 14.2 you will additionally need the following four packages (required to compile the ‘dav1d‘ decoder): meson, ninja, python3, python3-setuptools .

Where to find the new VLC packages:

Rsync access is offered by the mirror server: rsync://slackware.nl/mirrors/people/alien/restricted_slackbuilds/vlc/ .

For BluRay support, read a previous article for hints about the aacs keys that you’ll need.

My usual warning about patents: versions that can not only DEcode but also ENcode AAC audio can be found in my alternative repository where I keep the packages containing code that might violate stupid US software patents.

Chromium 64 – and 32bit pain

The new release of the Chromium sources gives us version 64 of Google’s browser. I have created Slackware packages for you, but that was not entirely trivial.
The Chromium compilation on my 32bit Slackware OS kept failing on the embedded ffmpeg. I am afraid the fact that some of the bigger distros are dropping 32bit variants starts showing and things are coming apart at the seams.
When you are a developer and there’s no 32bit release of your favorite OS, this makes it quite difficult to test the validity of code paths when you only compile and test your code on a 64bit platform. This is what’s happening with Google’s Chromium code and it will probably only get worse.

For now, I could get away by disabling assembly code in the 32bit avcodec library, but in order to get that going I had to study the Chromium code carefully – Google does not use the standard autotools or cmake configurations that the Average Joe would employ when compiling ffmpeg, instead they re-invent the wheel every so often to keep everyone on edge. First it was Gyp, but that did not work out too well and the current fad is called GN (as Google state themselves “GN is a meta-build system that generates Ninja build files so that you can build Chromium with Ninja“).

Some time soon, I need to dissect Chromium’s embedded ffmpeg code, to see if I can get assembly code compiling again on 32bit. Else it may be more prudent to start depending on an external (system-wide) ffmpeg installation, which I can compile without any pain on 32bit Slackware.

We’re fine for now, at least. Let’s hope it does not get worse.

Get your chromium 64 packages for Slackware 14.2 and -current:

Cheers, Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑