Skip to content

Conversation

@newbluemoon
Copy link
Contributor

@newbluemoon newbluemoon commented Dec 31, 2025

Testing the changes

  • I tested the changes in this PR: YES

Tested on x86_64 and aarch64:

  • hardcoded subtitles
  • DVB subtitles

New package

Local build testing

  • I built this PR locally for my native architecture, (x86_64)
  • I built this PR locally for these architectures (if supported. mark crossbuilds):
    • aarch64 (cross)
    • aarch64-musl (cross)
    • armv7l (cross)
    • armv7l-musl (cross)
    • i686
    • x86_64-musl

Fails to build on 32 bit targets, reported upstream and is fixed in upcoming 0.96.4.
Edit: all builds succeed now.

@newbluemoon
Copy link
Contributor Author

ccextractor cannot be built without gpac now, but the latest release 2.4.0 is from april 2024. So with respect to the upcoming ffmpeg 8 update I used the latest snapshot instead of the release, because there have been quite some code changes with respect to ffmpeg which make patching 2.4.0 to support ffmpeg 8 troublesome with the potential for unwanted side effects.

I have runtime tested ccextractor plus gpac-2.4.0.20251230 with ffmpeg 6 on x86_64 and aarch64 and with ffmpeg 8 on aarch64, working great, no problems found.

@classabbyamp
Copy link
Member

all packages should be on stable releases. if it's infeasible, petition the upstream for a new release or keep ccextractor at an older release

@classabbyamp
Copy link
Member

or alternatively, use an older ffmpeg for now

@newbluemoon
Copy link
Contributor Author

@classabbyamp I switched this PR back to the stable gpac release. Somehow I was under the assumption that ffmpeg8 will replace ffmpeg6, but 6 will still be there and so we can keep ccextractor at that version, as you suggested. :)

But I will also inquire gpac upstream if a new release is possible. However, they write here https://gpac.io/downloads/gpac-nightly-builds/:

GPAC releases don’t follow a fixed schedule! We maintain a solid CI/CD system to keep everything reliable. Even-numbered versions are stable releases, while odd-numbered versions are development builds, see blog post for details.

...

The current GPAC release is 2.4, released on 2024-04-17.

However, we recommend using the Nightly Builds (below) to get the most up-to-date version of GPAC.

They also have tags per abi version. Don’t know if this would be a proper alternative in case no release happens.

@classabbyamp
Copy link
Member

would it make sense to split this into gpac (binaries etc) and libgpac (library)? are the library and guis closely intertwined? for example, are /usr/lib/gpac/gm_*.so for the binaries or library or both?

@newbluemoon
Copy link
Contributor Author

ccextractor works just fine with /usr/lib/libgpac.so.... alone so it seems libgpac.so doesn’t depend on /usr/lib/gpac/gm_*.so and I split it off into a stand alone package libgpac. Thanks for the hint :)

Debian does the same and goes even further putting /usr/lib/gpac/gm_*.so into a separate package gpack-modules-base and makes gpac depend on it, but I think that’s a bit too much assuming that the gm_*.sos are only used by gpac itself.

@classabbyamp classabbyamp merged commit 10c002e into void-linux:master Jan 4, 2026
8 checks passed
@newbluemoon newbluemoon deleted the ccextractor branch January 4, 2026 20:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants