Compiling GStreamer plugin

Applications C++
#1

Does someone have experience with compiling a GStreamer plugin and could post step by step instructions on how to do it? Sadly, it’s not as easy as building a normal project, and so far my attempts to do it failed.

There are both latest versions of GStreamer itself as well as variety of plugins (base, good, bad, etc) compiled and readily available from OpenRepos but they all miss that specific one plugin that I need, i.e. modplug (support for Tracker music like Amiga MOD, XM, S3M, IT, etc). The modplug plugin is in bad plugins, but in “ext” folder (which I guess means “extras”), which isn’t included in any of the builds…

Long ago someone built that plugin (also available on OpenRepos but it was still in GStreamer 0.1 times and it doesn’t work anymore with GStreamer 1.0.

So, would someone please be able to help with either instructing how to build it or simply compiling it? The source code of bad plugins is here

2 Likes
#2

I have no experience with that, but I’m glad that there’s someone willing to a additional Codecs. I really want support for

  • ALAC (Apple Lossless)
  • heic
  • H.265
#3

ALAC: there is no ALAC-gstreamer-plugin, solution is to compile yourself a ALAC-enabled version of ffmpeg and use it via gstreamer1.0-libav package in all gstreamer apps…

H.265: support available since Sept’2016 in lpr repo @ openrepos (you’ll need libde265 from external source libde265 ( HEVC decoder ) | OpenRepos.net — Community Repository System) and the available version of gstreamer1.0-plugins-bad

1 Like
#4

As for the modplug plugin:

  1. @lpr compiled the latest bad plugins for gstreamer 1.20 (see here), including the modplug plugin. But it requires replacing quite a few packages to update Jolla’s current gstreamer (1.18?) to 1.20.

  2. As I didn’t want to mess with the SFOS’ current default gstreamer installation, I eventually managed to find version 1.16 of gstreamer-plugins-bad compiled for armv7hl architecture (built for Fedora) here. It is enough to install libmodplug decoder lib and then manually extract libgstmodplug.so from the aforementioned plugins-bad rpm and just copy it to /usr/lib/gstreamer-1.0/

Works like a charm!

Now I’ll need to start hunting for aarch64 builds, or keep trying to build them myself.

1 Like
#5

Yes, copying the codec was working in XA2, @lpr pointed me that way some time ago. I tried the same on 10 III with the Alac codec (but moved it to the lib64 folder instead of lib cause 10 III has no gstreamer folder in lib, I guess that depends ob the System architecture), but that didn’t work.

#6

For the 10 III (and II) you need the aarch64 build of the codec (and gstreamer plugin as well). They must be compiled specifically for the aarch64 architecture (look for .aarch64 in the package name instead of .armv7hl). Copying 32-bit libs to lib64 folder won’t work.

1 Like
#7

So it seems I’ll sadly will have to wait for someone to make a package for arch64… :frowning:

Nevertheless I don’t understand why Jolla doesn’t simply adds some more standard codecs to the system itself.

Nearly every device today can handle alac, heic, h.265 files out of the box (and maybe other codecs too). As far as I know these three I mentioned could be used licence-free.

@flypig Could that perhaps be discussed at the next meeting on 23. june? I think I won’t be able to join (cause of that I didn’t add it to the meeting thread) but the intention of the topic should be clear.

Community meeting on IRC 23rd June 2022
#8

Yes, of course! But I’d suggest you should make a proper question out of it and add it to the meeting thread anyway. Even if you can’t make it, it’ll force us to discuss it, and otherwise it’s likely to get lost amongst all the other discussion.

#9

Try searching for the plugins you need compiled for aarch64 for other Linux platforms, like e.g. OpenSuSE. This way I already found the modplug plugin compiled for aarch64, so maybe you’ll be able to find what you need, too…

#10

For info @Cryx, following your community meeting questiom, @abranson has merged his ALAC changes, so these will now be enabled in the next Sailfish OS release.

5 Likes
#11

viewing heic files is now possible:
you’ll need imageSDLview | OpenRepos.net — Community Repository System (that is the viewer) + libheif | OpenRepos.net — Community Repository System + gdk-pixbuf-loader-libheif | OpenRepos.net — Community Repository System

4 Likes
#12

can you please provide help how to build gstreamer / plugins-base ?

i want to try fix buffering issue Jolla-mediaplayer choppy playback while streaming by inspiration from here: [QMultimedia/GStreamer] Set the buffer size higher to avoid stuttering - together.jolla.com
but first i want to be sure that i will be able to compile it before do any changes…

tried method described here Building packages - advanced techniques | Sailfish OS Documentation

cloned GitHub - sailfishos/gstreamer
but failing to build:

FAILED: libs/gst/helpers/ptp/libgst_ptp_helper_conf.rlib 
rustc -C linker=cc --color=always --crate-type rlib --edition=2018 -C relocation-model=pic --crate-name gst_ptp_helper_conf --emit dep-info=libs/gst/helpers/ptp/gst_ptp_helper_conf.d --emit link -o libs/gst/helpers/ptp/libgst_ptp_helper_conf.rlib libs/gst/helpers/ptp/conf_lib.rs
error: failed to create encoded metadata from file: No such device (os error 19)

error: aborting due to previous error

i have no idea … :slight_smile:

#13

I have no idea either and with Jolla concentrating on crap like the C2 and the Mind box, there’s little to no hope of such problems ever being fixed, the stuttering has been there almost as long as sailfish has been around. I personally, have little to no interest in this problem, I built my own app which streams my favourite internet station with aplomb. Not sure why Jolla can’t make the adjustments to their abysmal mediaplayer, no point in asking, they are not interested. My app even displays track name/bitrate/etc, where as the jolla mediaplayer app displays “unknown artist” - doing it together?, what a fkin joke!

#14

hm, not sure that the new rust options in spec-file are activated correctly:

    # When cross-compiling under SB2 rust needs to know what arch to emit
    # when nothing is specified on the command line. That usually defaults
    # to "whatever rust was built as" but in SB2 rust is accelerated and
    # would produce x86 so this is how it knows differently. Not needed
    # for native x86 builds
    %ifarch %arm
    export SB2_RUST_TARGET_TRIPLE=armv7-unknown-linux-gnueabihf
    %endif
    %ifarch aarch64
    export SB2_RUST_TARGET_TRIPLE=aarch64-unknown-linux-gnu
    %endif
    # This avoids a malloc hang in sb2 gated calls to execvp/dup2/chdir
    # during fork/exec. It has no effect outside sb2 so doesn't hurt
    # native builds.
    %ifnarch %{ix86}
    export SB2_RUST_EXECVP_SHIM="/usr/bin/env LD_PRELOAD=/usr/lib/libsb2/libsb2.so.1 /usr/bin/env"
    export SB2_RUST_USE_REAL_EXECVP=Yes
    export SB2_RUST_USE_REAL_FN=Yes
    %endif

you’ll need latest sdk for sure but I don’t know if that’s sufficient…
gstreamer 1.24.x is not in SFOS4.6 (still 1.22.x)…
maybe you should try 1.22.12 which doesn’t use rust or if it has to be 1.24 switch off ptp-helper:

-Dptp-helper=disabled

you’ll have to remove

%{_libexecdir}/gstreamer-%{majorminor}/gst-ptp-helper

then from spec-file

1 Like
#15

thanks, without ptp-helper i can build gs 1.24
anyway good point is that in SFOS4.6 is still 1.22.10 so i switched to the older version and built with no issues and same with plugins-base