Package Details: lib32-gst-plugins-bad 1.24.0-2

Git Clone URL: https://aur.archlinux.org/lib32-gst-bad-ugly.git (read-only, click to copy)
Package Base: lib32-gst-bad-ugly
Description: Multimedia graph framework (32-bit) - bad plugins
Upstream URL: https://gstreamer.freedesktop.org/
Licenses: LGPL
Replaces: lib32-gst-plugins-bad-latest
Submitter: ahmubashshir
Maintainer: ahmubashshir (MarsSeed)
Last Packager: ahmubashshir
Votes: 46
Popularity: 1.18
First Submitted: 2023-01-07 17:47 (UTC)
Last Updated: 2024-04-18 18:37 (UTC)

Pinned Comments

ahmubashshir commented on 2023-11-18 14:43 (UTC) (edited on 2023-11-18 14:44 (UTC) by ahmubashshir)

If you have any improvements/suggestions for the pkgbuilds I maintain, please create an issue/pr on github.com/ahmubashshir/pkgbuilds or send the patches to ahmubashshir+pkgbuilds@gmail.com

p.s. sorry for being late, I was busy with my mid and part-time job last three months... it was truly chaotic...

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 20 Next › Last »

ApolloFortyNine commented on 2023-10-02 04:59 (UTC)

Needs lib32-mjpegtools added as a build dependency, or do what svallinn mentioned.

Arbyste commented on 2023-09-07 01:38 (UTC) (edited on 2023-09-07 01:39 (UTC) by Arbyste)

It looks like all the runtime dependencies for this package have been included in split package depends functions, e.g. 

package_lib32-gst-plugins-bad() {
  pkgdesc+=" - bad plugins"
  replaces=('lib32-gst-plugins-bad-latest')
  depends=(
    "lib32-gst-plugins-bad-libs>=$pkgver" lib32-aom lib32-libass...

However, note the following from the pkgbuild man page: "Note that makepkg does not consider split package depends when checking if dependencies are installed before package building and with --syncdeps. All packages required to make the package are required to be specified in the global depends and makedepends arrays."

I also tested this myself, any missing dependencies in the global depends() function were caught by makepkg, but missing dependencies inside package specific depends() functions were not caught.

It would probably be a good idea to collect all the runtime dependencies into a single, global depends() function, just like the build dependencies.

MarsSeed commented on 2023-07-18 22:39 (UTC)

The unneeded lib32-libnice 1.6.4 has a defect coming from upstream, which makes it unbuildable.

Though it can be quickly fixed with a patch, but it would be best to disable that dependency here, as well as lib32-webrtc-audio-processing, with the -D gst-plugins-bad:webrtc=disabled option.

svallinn commented on 2023-07-17 19:56 (UTC)

You guys forgot -D gst-plugins-bad:mplex=disabled, mplex depends on lib32-mjpegtools which the package no longer uses.

MarsSeed commented on 2023-07-16 17:28 (UTC)

After some more digging, I am seeing that lib32-webrtc-audio-processing would also be good to remove, by turning off the 'webrtc' meson option inside gst-plugins-bad.

This is again too new technology for 15+ year old bin32 tools to support.

And lib32-libnice was added by repo in 2018 to gst-plugins-bad to be used with one of the webrtc plugins. It is useless for any other purposes.

MarsSeed commented on 2023-07-11 16:47 (UTC)

lib32-spandsp, a "DSP library for telephony", should also not be needed in 32-bit in my view.

MarsSeed commented on 2023-07-11 14:48 (UTC) (edited on 2023-07-11 15:02 (UTC) by MarsSeed)

Some people reported unresolved build problems with lib32-gsm in Jan 2023.

I can wholeheartedly recommend that you turn that off as well in this build. I cannot imagine anyone wanting to use the old, low-quality GSM mobile audio format, in a 32-bit software or otherwise. VoIP applications are available in 64-bit and support much better codecs as well, and VoIP-to-POTS services also allow other codecs.

(And again, GSM compressed audio recordings can still be used with 64-bit multimedia software.)

MarsSeed commented on 2023-07-11 14:35 (UTC) (edited on 2023-07-11 15:46 (UTC) by MarsSeed)

And lib32-zbar can also be dropped in my opinion. Anyone who wants to read barcodes, QR codes etc. can do so with 64-bit software. Or if somehow someone still has e.g. an old 32-bit Windows program for that, such software would use its own DLL library for this functionality, and wouldn't need lib32-gstreamer for it.

MarsSeed commented on 2023-07-11 14:28 (UTC) (edited on 2023-07-11 15:48 (UTC) by MarsSeed)

You can also disable lib32-chromaprint, which is a heavy library necessitating lib32-ffmpeg, and which is only used for audio fingerprinting (sound analysis based music identification). All software that one would need for that purpose is available in 64-bit, and this functionality was never used by games, workstation / office apps, digital encyclopedias, etc.

MarsSeed commented on 2023-07-11 14:16 (UTC) (edited on 2023-07-11 16:03 (UTC) by MarsSeed)

Hi,

I recommend that you drop and disable using lib32-openjpeg2. I did some digging, and it turns out that it is only for JPEG2000 video stream, which is a format I have yet to see used in my life. Digital cameras used to create MJPEG videos, that is a different format. And no desktop multimedia software or game would ship their videos in this obscure, non-delta-compressed format, which would result in unnecessarily huge files.

If someone has video recordings from digital cameras in JPEG2000 video, they would still be able to open and play those in 64-bit media players and editors, through repo's gst-plugins-bad or ffmpeg.

By this same logic, you can disable lib32-mjpegtools, as again, all the multimedia handling software one needs is available in 64-bit nowadays, and games never, ever used the MJPEG format.

Also, if some 32-bit-only desktop software would want to open from or save to JPEG2000 picture files, they would not (and could not) use gstreamer for it, but instead call openjpeg2 or some other JPEG2000 library directly.

Edit: turns out that FFMPEG has an internal JPEG2000 video codec which is even faster. So if someone happens to need this video format in a 32-bit application, they can do so via lib32-ffmpeg, or its wrapper, lib32-gst-libav. So definitely no need for lib32-openjpeg2 support here.

Edit 2: FFMPEG also supports the MJPEG format natively.

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 20 Next › Last »