Arch Linux User Repository

And here are the changes needed to compile against ffmpeg7 which just recently landed:

diff -ru libquicktime-1.2.4.orig/plugins/ffmpeg/audio.c libquicktime-1.2.4/plugins/ffmpeg/audio.c
--- libquicktime-1.2.4.orig/plugins/ffmpeg/audio.c  2024-07-09 12:18:11.919376601 +0200
+++ libquicktime-1.2.4/plugins/ffmpeg/audio.c   2024-07-09 12:10:53.297276614 +0200
@@ -971,7 +971,11 @@
   if(!codec->initialized)
     {
     /* Set some mandatory variables */
+#if LIBAVCODEC_VERSION_INT >= AV_VERSION_INT(61, 0, 0)
+    codec->avctx->ch_layout.nb_channels = quicktime_track_channels(file, track);
+#else
     codec->avctx->channels        = quicktime_track_channels(file, track);
+#endif
     codec->avctx->sample_rate     = quicktime_sample_rate(file, track);

     if(track_map->track->mdia.minf.stbl.stsd.table[0].version == 1)
@@ -1202,7 +1206,11 @@
   if(!codec->initialized)
     {
     codec->avctx->sample_rate = track_map->samplerate;
+#if LIBAVCODEC_VERSION_INT >= AV_VERSION_INT(61, 0, 0)
+    codec->avctx->ch_layout.nb_channels = channels;
+#else
     codec->avctx->channels = channels;
+#endif

     codec->avctx->codec_id = codec->encoder->id;
     codec->avctx->codec_type = codec->encoder->type;
@@ -1229,7 +1237,11 @@
     /* One frame is: bitrate * frame_samples / (samplerate * 8) + 1024 */
     codec->chunk_buffer_alloc = ( codec->avctx->frame_size
                                   * sizeof( int16_t )
+#if LIBAVCODEC_VERSION_INT >= AV_VERSION_INT(61, 0, 0)
+                                  * codec->avctx->ch_layout.nb_channels);
+#else
                                   * codec->avctx->channels);
+#endif
     codec->chunk_buffer = malloc(codec->chunk_buffer_alloc);

     if(trak->strl)

@RAMChYLD, this needs a minor touchup in qtpng.c to compile with gcc14:

diff -ru libquicktime-1.2.4.orig/plugins/png/qtpng.c libquicktime-1.2.4/plugins/png/qtpng.c
--- libquicktime-1.2.4.orig/plugins/png/qtpng.c 2011-01-07 15:40:46.000000000 +0100
+++ libquicktime-1.2.4/plugins/png/qtpng.c  2024-06-19 11:04:51.460483842 +0200
@@ -26,6 +26,7 @@
 #include <quicktime/colormodels.h>
 #include <png.h>
 #include <stdlib.h>
+#include <string.h>
 #include "qtpng.h"

 typedef struct

You can also grab the updated PKGBUILD and patch here: https://build.opensuse.org/package/show/home:aggraef:test/libquicktime

@RAMChYLD, seems to work fine with Gem for me. Thanks a bunch for taking over maintenance of the package, and for adding the necessary patches for modern ffmpeg support, I really appreciate it!

Integrated patch for ffmpeg5. Let me know if it works.

@apaz: Sorry, I'm not interested in maintaining a gazillion patches for a dead project. Either someone picks up the project or downstreams adapt and move to something else.

If it is of interest there is a discussion in the Debian bug report to implement libquicktime in ffmpeg 5: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004637 Here is the patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1004637;filename=24-ffmpeg5.patch;msg=14

Until it does, can't you make a single exception for one of the most iconic pieces of Linux multimedia software? Please? :)

That doesn't change anything about it being essential a dead project and ffmpeg5 support being non-existent. I can move pd-gem to the AUR, in case you want to maintain it. I don't use it and it's more work than anything unfortunately. I also do not believe that upstream will have the time to improve it drastically over the next decade judging from the past years of development.

Call it legacy, but Pd+Gem is one of the cornerstones of Linux multimedia which has been around forever. It's sad to see such an important piece of software being severely hampered in its multimedia capabilities.

dvzrv, I understand your reasoning, I really do, but libquicktime is essential for Gem's video functionality. Without it there are no video loading capabilities to speak of, and video recording is severely limited as well. I'd say that this is pretty essential stuff for students, media artists and other professionals using Gem's video functionality. If you don't believe me, just try loading any of the videos in Gem/examples/04.pix/05.movie.pd. With your pd-gem package, you'll only get a single frame, which is utterly useless.

I also think that Gem should get a new video backend that doesn't rely on legacy software. But that doesn't happen just because I wish for it. Until it does, can't you make a single exception for one of the most iconic pieces of Linux multimedia software? Please? :)

This package is still available in Debian Unstable, so it's unfortunate that it's not in the Arch community repo any more. We need it if we want to package Gem for Pd, which (at least for media artists) is the single most important add-on library for Pd (which still is in community). So it would be nice if you could reconsider the decision to drop libquicktime from the official repos.

The pd-gem package in [community] is built without libquicktime support. I have no interest in bringing libquicktime back if there has not been a release in 10 years and it would mean adding more and more patches to make it work with ffmpeg4.4, which will be removed from the repositories soon as well. Energy is better spent on doing something else than to fix up someone else's legacy ;-)

@dvzrv, libquicktime isn't dead, Steven Schultz has been maintaining it since 2018. It's true that it hasn't seen a proper release since 2.1.4 in 2012, but with the patches included here it compiles fine against ffmpeg 4.4, and it also still works with the little adjustment to the PKGBUILD which I just posted.

This package is still available in Debian Unstable, so it's unfortunate that it's not in the Arch community repo any more. We need it if we want to package Gem for Pd, which (at least for media artists) is the single most important add-on library for Pd (which still is in community). So it would be nice if you could reconsider the decision to drop libquicktime from the official repos.