68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.

Compiling MacFlim's flimmaker on ARM - Raspberry Pi?

Posted by: avadondragon on 2023-01-30 18:06:04

So I finally decided to play around with MacFlim today and man is it AWESOME!

I wanted to try converting my own videos so I thought I would try compiling flimmaker on my PiSCSI so I could just create the flim files right where I was going to use them. Everything seemed to go smoothly but once everything compiled it seemed like the binary created was the wrong architecture perhaps?

When I tried to run ./flimmaker it returned the following:
bash: ./flimmaker: cannot execute binary file: Exec format error

Posted by: sfiera on 2023-01-30 21:12:52

What does file flimmaker say about the file type?

Posted by: avadondragon on 2023-01-30 22:31:30

What does file flimmaker say about the file type?

Welp there's the problem.
It says x86-64

Posted by: Melkhior on 2023-01-30 23:16:20

There's an x86-64 binary is the src/ directory on GitHub which you want to ignore.
In src/ you simply do 'make ../flimmaker', then the aarch64 binary should in the top-level directory (provided you have the dependencies installed such as libavformat).

Posted by: avadondragon on 2023-01-31 05:10:18

There's an x86-64 binary is the src/ directory on GitHub which you want to ignore.
In src/ you simply do 'make ../flimmaker', then the aarch64 binary should in the top-level directory (provided you have the dependencies installed such as libavformat).

Thank you. 🙂

Posted by: avadondragon on 2023-01-31 14:34:01

Well turns out this was a lost cause. I guess flimmaker needs too much memory. I watched it fill up the RAM and the SWAP then it died. It might work on the 8GB version of the pi 4 I guess.

Posted by: just.in.time on 2023-04-30 22:48:52

@avadondragon did you ever get this working on a raspberry Pi 4gb model? I also am running into an issue with it. Reads around 4100 frames then crashes in Terminal or the entire Pi freezes.

Posted by: avadondragon on 2023-04-30 23:27:06

I eventually gave up. It eats up HUGE amounts of RAM. I ended up running it on a Linux machine with 16GB and it used most of it.

Posted by: just.in.time on 2023-05-01 22:41:42

Thanks for the quick reply! Okay sounds good, I’ll give it a try on another system.

Posted by: robin-fo on 2023-05-02 01:15:41

I eventually gave up. It eats up HUGE amounts of RAM. I ended up running it on a Linux machine with 16GB and it used most of it.

Sounds like a memory leak or inefficient programming 😅

Posted by: just.in.time on 2023-05-04 09:14:50

This was an adventure. Tried installing WSL on an existing Windows 10 Bootcamp install on my old MacBook (16gb RAM). For whatever reason something wasn’t working right with it, strange errors and never got it to get to point of encoding video frames.

Ended up installing Linux Mint on a spare SSD in my gaming computer (which has 32gb RAM, so I figured it should cover it). This setup worked great. While it was running the first few test runs I kept watch on “top” in a separate terminal window and saw it using up just under 12gb of RAM (explains why the raspberry pi kept failing like you said @avadondragon ).

Only strange thing I noticed with the Linux code (not sure if issue is in macsrc version as well, didn’t bother to check), is that the program tries to download the video using both yt-dlp AND youtube-dl, when it should only be using youtube-dl as a fallback if yt-dlp failed/errored. The result is that the program would then exit since YouTube-dl is no longer current (at least on my Pi or Linux Mint install) and errors out.

My solution to this issue was to navigate to src and open flimmaker.cpp , comment out line 650 (“exit( EXIT_FAILURE );”), save changes, and rerun “make” command. If I really wanted to clean it up well I could completely remove all YouTube-dl related code and the fallback conditions, but this at least stops the program from closing out without completing.

Posted by: luRaichu on 2025-04-24 09:33:10

Has anyone compiled flimmaker 2.0 on Windows/Cygwin or WSL lately?
I have a friend who wants to encode their own flims on an ARM thinkpad running Windows 11.

Posted by: fstark on 2026-01-03 15:04:55

I eventually gave up. It eats up HUGE amounts of RAM. I ended up running it on a Linux machine with 16GB and it used most of it.

(author here)
It absolutely is badly coded, and loads all the frames in memory. It is not suitable to make flims longer than around 3 minutes on my 32Gb machine. I have a branch where I work on getting the beast tamed, but it isn't as high priority as it probably should...

Posted by: fstark on 2026-01-03 15:11:35

This was an adventure. Tried installing WSL on an existing Windows 10 Bootcamp install on my old MacBook (16gb RAM). For whatever reason something wasn’t working right with it, strange errors and never got it to get to point of encoding video frames.

Ended up installing Linux Mint on a spare SSD in my gaming computer (which has 32gb RAM, so I figured it should cover it). This setup worked great. While it was running the first few test runs I kept watch on “top” in a separate terminal window and saw it using up just under 12gb of RAM (explains why the raspberry pi kept failing like you said @avadondragon ).

Only strange thing I noticed with the Linux code (not sure if issue is in macsrc version as well, didn’t bother to check), is that the program tries to download the video using both yt-dlp AND youtube-dl, when it should only be using youtube-dl as a fallback if yt-dlp failed/errored. The result is that the program would then exit since YouTube-dl is no longer current (at least on my Pi or Linux Mint install) and errors out.

My solution to this issue was to navigate to src and open flimmaker.cpp , comment out line 650 (“exit( EXIT_FAILURE );”), save changes, and rerun “make” command. If I really wanted to clean it up well I could completely remove all YouTube-dl related code and the fallback conditions, but this at least stops the program from closing out without completing.

Oh. If this is still the case, please enter an issue in github, I'll fix it for everyone!

On github, the releases now include a ZIP file with a working windows binary, I look into adding an ARM one.

You can track https://github.com/fstark/macflim/issues/52 for progress.

Any question, whatever, I've put a discord server for easier troubleshooting.

Join the macflim Discord Server!

Check out the macflim community on Discord - hang out with 8 other members and enjoy free voice and text chat.

discord.gg

Thx for using MacFlim!

Posted by: fstark on 2026-01-03 15:40:55

Well, I added an Windows ARM64 build. It does build, don't know if it works well enough...

You can find it in all MacFlim release starting at 2.0.16:

Release v2.0.16 · fstark/macflim

What's New? Fixed memory allocation of Mini MacFlim for Multi-Finder execution (default of 350K is too low as prefs wants 300K of buffers) First version of the Windows ARM package Installation Clas...

github.com

Let me know if it works or is borken.

Posted by: just.in.time on 2026-01-03 17:44:26

@fstark Thank you for putting this together! Definitely a cool utility to have for vintage Macs. I'll have to download the latest version and see if issue mentioned a while back is still present. If it is, I'll follow your note above to get an issue entered into GitHub.