Package Details: lib32-gst-plugins-bad-libs 1.24.8-1

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
Upstream URL: https://gstreamer.freedesktop.org/
Licenses: LGPL
Replaces: lib32-gst-plugins-bad-libs-latest
Submitter: ahmubashshir
Maintainer: ahmubashshir (MarsSeed)
Last Packager: ahmubashshir
Votes: 46
Popularity: 0.022775
First Submitted: 2023-01-07 17:47 (UTC)
Last Updated: 2024-10-28 05:13 (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 9 10 .. 21 Next › Last »

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.

FabioAreia commented on 2023-05-23 19:27 (UTC)

@francescoz96 is right

Dependency need to bump again

francescoz96 commented on 2023-05-21 10:46 (UTC)

@ahmubashshir, would it be better if you replace this in line 207 of the PKGBUILD:

"lib32-gst-plugins-base-libs=$pkgver" lib32-libxkbcommon-x11 lib32-orc

with

"lib32-gst-plugins-base-libs>=$pkgver" lib32-libxkbcommon-x11 lib32-orc

to avoid this kind of issues altogether?

Forcing a specific version of a package is never a good idea, IMHO...

ahmubashshir commented on 2023-05-15 00:35 (UTC) (edited on 2023-05-15 00:37 (UTC) by ahmubashshir)

@bez_ussj, @HealerLFG, try building it in a clean chroot. it should work. or use aurutils to automate the task.

this is not a -bin pkgbuild, I've already bumped versions, just rebuild and install.

bez_ussj commented on 2023-05-13 22:15 (UTC) (edited on 2023-05-13 22:19 (UTC) by bez_ussj)

HealerLFG commented on 2023-05-07 23:41 (BST) (edited on 2023-05-07 23:42 (BST) by HealerLFG)

Dependency version bump needed:

The package lib32-gst-plugins-bad-libs depends on version =1.22.1 of lib32-gst-plugins-base-libs, but the most recent version is 1.22.2.

The package lib32-gst-plugins-ugly depends on version =1.22.1 of lib32-gst-plugins-base-libs, but the most recent version is 1.22.2.

This is still the case - I have been unable to fully update my system as a result

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