Open-source software currently supported on macOS PowerPC

[barracuda156]

Instead of torturing the latest version of Mono to build, I decided to start with the old one which upstream built for ppc the last (2.10.2). That worked with minor fixes, and apparently Mono works now (at least Nant builds successfully).

I will see how far it can be updated without enormous pain.

2.10.2 is committed now.

 

[barracuda156]

glances

 

[barracuda156]

Trackma: a GUI/CLI client for MyAnimeList / Anilist etc.

A quick test confirmed that synchronization works both ways (website to the mac and reverse, tested on powerpc and x86_64).

P. S. Logging in to MAL account needs a PIN (not an account password), which is generated on request. Do not do it from the GUI, PowerFox crashes, Aquafox cannot even connect. Do it from CLI, copy the auth link, generate PIN on another machine with a modern browser, pass the code back to powerpc. Slightly annoying, but once done, it works in GTK GUI with no issues.

 

[Matias_]

Oooh this is cool!

PS: Rock wa Lady, nice. Planning to watch it since an IRC friend recommend it to me 🙂

 

[srp]

On the topic of mrustc and some of the Rust ports that are available, I benchmarked `ripgrep` vs regular `grep` version 3.12 (both from macports) and I found that `ripgrep` was markedly slower.

Searching my user directory for string "TODO":

Benchmark runs:
Run 1:
rg     matches=301      real=37.33    user=13.92    sys=5.51
ggrep  matches=302      real=30.43    user=11.40    sys=5.30

Run 2:
rg     matches=301      real=37.18    user=13.93    sys=5.65
ggrep  matches=302      real=30.00    user=11.41    sys=5.25

Run 3:
rg     matches=301      real=36.94    user=13.90    sys=5.57
ggrep  matches=302      real=31.97    user=11.42    sys=5.30

I thought this was interesting because Rust ports should be way faster than this.

It would be cool if we had a fully optimized and working `rg` and hopefully even `fd`, `jaq`, `delta`, `tokei` - these would all be meaningful for the agentic code editor features I'm working on.

 

[barracuda156]

On the topic of mrustc and some of the Rust ports that are available, I benchmarked `ripgrep` vs regular `grep` version 3.12 (both from macports) and I found that `ripgrep` was markedly slower.

Searching my user directory for string "TODO":

Benchmark runs:
Run 1:
rg     matches=301      real=37.33    user=13.92    sys=5.51
ggrep  matches=302      real=30.43    user=11.40    sys=5.30

Run 2:
rg     matches=301      real=37.18    user=13.93    sys=5.65
ggrep  matches=302      real=30.00    user=11.41    sys=5.25

Run 3:
rg     matches=301      real=36.94    user=13.90    sys=5.57
ggrep  matches=302      real=31.97    user=11.42    sys=5.30

I thought this was interesting because Rust ports should be way faster than this.

It would be cool if we had a fully optimized and working `rg` and hopefully even `fd`, `jaq`, `delta`, `tokei` - these would all be meaningful for the agentic code editor features I'm working on.

Compared to C/C++ rust versions aren’t supposed to be faster. But yes, mrustc doesn’t produce optimized code, I guess.

Re grep, did you try krep port?
There may also be OCaml replacements, though on ppc OCaml uses bytecode, which isn’t the fastest either.

 

[srp]

Compared to C/C++ rust versions aren’t supposed to be faster.

Huh? It should be the opposite. Rust is being shoehorned into everything right now because it's memory safe and in a lot of cases faster than C/C++.


ripgrep is faster than {grep, ag, git grep, ucg, pt, sift}

 

[barracuda156]

Huh? It should be the opposite. Rust is being shoehorned into everything right now because it's memory safe and in a lot of cases faster than C/C++.

Not really. It took off because Rust foundation was sponsoring it, which created a fanbase of developers. It still has a relatively minor foot-print outside of Reddit. Won't be faster than C++ in general case. Which is why speed-critical software is not being written in Rust (rather in C++ and Fortran).
But alleged “memory safety” is useful for marketing teams, heh.

 

[barracuda156]

By the way, cherrytree is fixed now:

 

[barracuda156]

Slightly on a side-note, I forgot in which topic, but there was a discussion re multimedia players comparison. Here is a rather random example file fetched from YouTube today (in abominable AV1 encoding): I tried mpv (sdl2 via Cocoa), mplayer and qmplay2-devel.

Results:

mplayer: video slowed down, audio is not playing at all;
mpv: video lags a bit less, audio lags;
qmplay2-devel: video may drop occasional frames, audio is normal, it is the only one which is actually watchable of the three.

PowerMac G5 2.3, Nvidia 6600.
I am eager to see some counter-example where qmplay2 performs worse than some other alternative.

 

[Forest Expertise]

Slightly on a side-note, I forgot in which topic, but there was a discussion re multimedia players comparison. Here is a rather random example file fetched from YouTube today (in abominable AV1 encoding): I tried mpv (sdl2 via Cocoa), mplayer and qmplay2-devel.

Results:

mplayer: video slowed down, audio is not playing at all;
mpv: video lags a bit less, audio lags;
qmplay2-devel: video may drop occasional frames, audio is normal, it is the only one which is actually watchable of the three.

PowerMac G5 2.3, Nvidia 6600.
I am eager to see some counter-example where qmplay2 performs worse than some other alternative.

View attachment 2602827

It's possible qmplay2-devel benefits a lot from OpenGL acceleration - I have a build without that enabled for Mac OS Tiger that is considerably less performant (though still correct) when using streamlink to stream any xfiles episode from plutotv. At the 1000k bitrate, a 1.5 Ghz PowerBook G4 on reduced mode (figure 750 Mhz) can stream an episode at roughly 70% CPU usage with @alex_free 's excellent ffplay (from PPCMC) with sound and video in sync, and, as far as I can tell, no frames dropped. The same PowerBook G4 needs full CPU power to play the same file with QMPlay2-devel, and still drops a few frames, though everything else is correct. Of course, that is on a build with no OpenGL acceleration, though with the +G4 variant and LTO.
My guess is that QMPlay2 is too heavy for the minimum Leopard/Snow Leopard configuration with a terrible graphics card like the Nvidia Geforce2 MX (which has no OpenGL 2 support) on an 867 Mhz PowerMac G4.
Your recommendation from your website that mplayer is preferred over QMPlay2 for resource constrained systems is likely correct. And in my experience, @alex_free 's ffplay build is an excellent balance of correctness (a struggle for mplayer), modernity (can stream over https!), and cpu usage (reasonable).
And for downloaded video in the codecs it supports, I don't really see any open source video player competing with coreplayer in low CPU usage, but coreplayer is lacking in ability to stream video and fails to play some modern codecs at all.
My guess is that with OpenGL enabled, QMPlay2 is probably best for any Power PC Mac that has a good OpenGL 2.0 supporting graphics card better than Nvidia FX Go 5200, but is likely not the best choice for those on a single slow G4 with a terrible graphics card.
The developer of QMplay2 did an amazing job with correctness, but it is understandably heavier than command line players without QMPlay2's excellent interface and features.

 

[barracuda156]

It's possible qmplay2-devel benefits a lot from OpenGL acceleration - I have a build without that enabled for Mac OS Tiger that is considerably less performant (though still correct) when using streamlink to stream any xfiles episode from plutotv. At the 1000k bitrate, a 1.5 Ghz PowerBook G4 on reduced mode (figure 750 Mhz) can stream an episode at roughly 70% CPU usage with @alex_free 's excellent ffplay (from PPCMC) with sound and video in sync, and, as far as I can tell, no frames dropped. The same PowerBook G4 needs full CPU power to play the same file with QMPlay2-devel, and still drops a few frames, though everything else is correct. Of course, that is on a build with no OpenGL acceleration, though with the +G4 variant and LTO.
My guess is that QMPlay2 is too heavy for the minimum Leopard/Snow Leopard configuration with a terrible graphics card like the Nvidia Geforce2 MX (which has no OpenGL 2 support) on an 867 Mhz PowerMac G4.
Your recommendation from your website that mplayer is preferred over QMPlay2 for resource constrained systems is likely correct. And in my experience, @alex_free 's ffplay build is an excellent balance of correctness (a struggle for mplayer), modernity (can stream over https!), and cpu usage (reasonable).
And for downloaded video in the codecs it supports, I don't really see any open source video player competing with coreplayer in low CPU usage, but coreplayer is lacking in ability to stream video and fails to play some modern codecs at all.
My guess is that with OpenGL enabled, QMPlay2 is probably best for any Power PC Mac that has a good OpenGL 2.0 supporting graphics card better than Nvidia FX Go 5200, but is likely not the best choice for those on a single slow G4 with a terrible graphics card.
The developer of QMplay2 did an amazing job with correctness, but it is understandably heavier than command line players without QMPlay2's excellent interface and features.

Do you know which GPU lacks GL 2.0? I can probably restore an older GL into QMPlay2 (I think I had a version like that, but then found out that 2.0 works too, so that patch was revised).

 

[Forest Expertise]

Do you know which GPU lacks GL 2.0? I can probably restore an older GL into QMPlay2 (I think I had a version like that, but then found out that 2.0 works too, so that patch was revised).

The full list for leopard is detailed here: http://developer.apple.com/graphicsimaging/opengl/capabilities/GLInfo_1058.html
Edit: Archived here https://web.archive.org/web/2012010...simaging/opengl/capabilities/GLInfo_1058.html
And here slightly differently: https://web.archive.org/web/2009092...simaging/opengl/capabilities/GLInfo_1058.html

They all have software support for OpenGL 2, but the following GPUs are considered supported by Leopard but do not offer any hardware support for OpenGL 2:

Radeon 9000/9200

Radeon 8500

Radeon 7200/7500

Radeon 7000

GeForce FX 5200
GeForce4 Ti
GeForce3
GeForce2 MX/4 MX

Of those, the GeForce2 MX/4 MX may be a lost cause, as it supports only OpenGL 1.1

 

[barracuda156]

The full list for leopard is detailed here: http://developer.apple.com/graphicsimaging/opengl/capabilities/GLInfo_1058.html
Edit: Archived here https://web.archive.org/web/2012010...simaging/opengl/capabilities/GLInfo_1058.html
And here slightly differently: https://web.archive.org/web/2009092...simaging/opengl/capabilities/GLInfo_1058.html

They all have software support for OpenGL 2, but the following GPUs are considered supported by Leopard but do not offer any hardware support for OpenGL 2:

Radeon 9000/9200

Radeon 8500

Radeon 7200/7500

Radeon 7000

GeForce FX 5200
GeForce4 Ti
GeForce3
GeForce2 MX/4 MX

Of those, the GeForce2 MX/4 MX may be a lost cause, as it supports only OpenGL 1.1

I have some PowerBooks which are supposed to have pathetic GPUs, perhaps I can try to see what works there. Ah, and i got a MacMini G4 too.

 

[Forest Expertise]

I have some PowerBooks which are supposed to have pathetic GPUs, perhaps I can try to see what works there. Ah, and i got a MacMini G4 too.

The Mini with an ATI Radeon 9200 is probably the best test machine, as I know that GPU only supports OpenGL 1.3, and not Quartz Extreme or Core Image. It's also used in a lot of machines that can't upgrade the GPU, and is a popular choice even in high end PowerMac G4s that want to dual boot into OS 9 with full graphics support.
Everything probably "works" as is because of the software renderer, I would just expect it to be slow.

 

[barracuda156]

The Mini with an ATI Radeon 9200 is probably the best test machine, as I know that GPU only supports OpenGL 1.3, and not Quartz Extreme or Core Image. It's also used in a lot of machines that can't upgrade the GPU, and is a popular choice even in high end PowerMac G4s that want to dual boot into OS 9 with full graphics support.
Everything probably "works" as is because of the software renderer, I would just expect it to be slow.

Qmplay2 shows whether GL is used, and it can be enabled/disabled in settings (or at the build time, after all), so it should be easy to see if it is used and if it makes a difference.

 

[Forest Expertise]

Qmplay2 shows whether GL is used, and it can be enabled/disabled in settings (or at the build time, after all), so it should be easy to see if it is used and if it makes a difference.

That's cool that is can be enabled or disabled in settings. Hopefully someone with the worst Leopard supported GPU (GeForce2 MX/4 MX) can let everyone know whether they get any improvement from OpenGL.
I think you are quite right that Qmplay2 is already the best choice on all but the low end of Leopard/Snow Leopard supported systems - the only question is whether it can become the best choice even for the very worst G4s with bad GPUs. The Imac G4 1 ghz appears to be the worst system that can run Leopard/A5 but is stuck with the GeForce2 MX/4 MX

 

[barracuda156]

mangadex-dl, new port: a utility to download manga from Mangadex

@Forest Expertise I have updated `kobodl` too now, please check that it still works, there are new dependencies.

 

[srp]

On the note of video playback, I recently made a Plex client with an OpenGL accelerated canvas that I render the video to with ffmpeg. The answer is yes - OpenGL hardware acceleration is the fastest way to play a video on capable hardware. Enabling double buffering helps with some codecs as well. My Plex player seems to be generally faster than QMPlay2 (although with my Plex client, the file is being streamed from local network vs via YouTube or stored locally) but not quite as fast as a direct ffplay call.

I am currently working on a software renderer for less capable devices - there are two good (native) pathways for this, the better performing one is a CoreImage presentation, and then the more compatible one would just be a simple Quartz2D drawing into an NSView.

The cool thing about Plex is that I have a wide range of different codecs and quality on my server, so I was able to do a lot of testing and profiling. Of the 5 video codecs I tested at various qualities - MPEG4, H264, HEVC, H265, and AV1 - AV1 was by far the slowest. H265 and HEVC are a close second and third. My HEVC content varied a lot in quality (e.g. I had 100GB 1080p Bluray remux movies and also 720p 6mbps movies) so it was a bit of a mixed bag but always tied directly to bitrate. Some 1080p HEVC content played fine, some was really slow.

H265 and AV1 the results were more clear - not going to run smoothly in 1080p, period.

I think this was a great testing platform for these codecs because I was able to write a modern optimized GL accelerated window and remove any other slow parts in the chain. I know it's not bottlenecking over I/O. From my understanding the reason these codecs fail to perform well is because there is no AltiVec acceleration - this would be a high impact contribution in my opinion. In the meantime, I've added a warning that appears when using these codecs, so we can at least inform the user they're likely to experience performance issues.

H264/MPEG4 content plays back flawlessly at 1080p on my Quad (7800GT). This makes about 60% of my Plex library playable.

 

[barracuda156]

On the note of video playback, I recently made a Plex client with an OpenGL accelerated canvas that I render the video to with ffmpeg. The answer is yes - OpenGL hardware acceleration is the fastest way to play a video on capable hardware. Enabling double buffering helps with some codecs as well. My Plex player seems to be generally faster than QMPlay2 (although with my Plex client, the file is being streamed from local network vs via YouTube or stored locally) but not quite as fast as a direct ffplay call.

Do you mean that the fastest playback for you is via ffplay? This is certainly not the case for me (I recall ffplay performs worse that many alternatives).

I am currently working on a software renderer for less capable devices - there are two good (native) pathways for this, the better performing one is a CoreImage presentation, and then the more compatible one would just be a simple Quartz2D drawing into an NSView.

The cool thing about Plex is that I have a wide range of different codecs and quality on my server, so I was able to do a lot of testing and profiling. Of the 5 video codecs I tested at various qualities - MPEG4, H264, HEVC, H265, and AV1 - AV1 was by far the slowest. H265 and HEVC are a close second and third. My HEVC content varied a lot in quality (e.g. I had 100GB 1080p Bluray remux movies and also 720p 6mbps movies) so it was a bit of a mixed bag but always tied directly to bitrate. Some 1080p HEVC content played fine, some was really slow.

H265 and AV1 the results were more clear - not going to run smoothly in 1080p, period.

I think this was a great testing platform for these codecs because I was able to write a modern optimized GL accelerated window and remove any other slow parts in the chain.

If you are good with GL (I am not), a big thing will be to properly fix GL in mpv and perhaps improve in QMPlay2.

I know it's not bottlenecking over I/O. From my understanding the reason these codecs fail to perform well is because there is no AltiVec acceleration - this would be a high impact contribution in my opinion.

Altivec was dropped in libvpx at some point, it should be possible to restore it. Though I am not sure it was used for VP9, maybe only for VP8.

In the meantime, I've added a warning that appears when using these codecs, so we can at least inform the user they're likely to experience performance issues.

H264/MPEG4 content plays back flawlessly at 1080p on my Quad (7800GT). This makes about 60% of my Plex library playable.

The Quad should do better than that actually (like, 4k at 30 fps should be usable).

 

[srp]

Do you mean that the fastest playback for you is via ffplay? This is certainly not the case for me (I recall ffplay performs worse that many alternatives).



If you are good with GL (I am not), a big thing will be to properly fix GL in mpv and perhaps improve in QMPlay2.



Altivec was dropped in libvpx at some point, it should be possible to restore it. Though I am not sure it was used for VP9, maybe only for VP8.



The Quad should do better than that actually (like, 4k at 30 fps should be usable).

QMPlay2 is the only player port I have tried and my experience has been absolutely awful. The base `qmplay2` port is just broken. Audio makes this horrible screeching noise on pretty much every video I try and then it eventually crashes. `qmplay2-devel` works, but it's definitely not faster than my Plex player or a raw ffplay command - the audio is stuttery and fails to keep up, it jumps all over the place. Not sure if this is because I'm on Leopard.

In my opinion, these are not very complex applications - it doesn't take much effort to make a proper native Cocoa application that can build as a universal binary and optimize it directly with Apple APIs like CoreImage - to me this is a much better investment of my time that would give a more polished and optimized result. A bad player will amplify the codec problems but even with a very optimized player taking advantage of native Leopard APIs and C++ 20 features, threading etc, the codec problems are laid bare.

The other thing I need to add support for is Plex transcoding - because then I can have the server do the heavy lifting and it just gives us a workable 1080p h264 stream in return.

Also, you're right about 4k! My copy of Ex Machina is h264 2160p and it plays back just fine with ffplay or with the OpenGL backend of my Plex player.

 

[barracuda156]

QMPlay2 is the only player port I have tried and my experience has been absolutely awful. The base `qmplay2` port is just broken. Audio makes this horrible screeching noise on pretty much every video I try and then it eventually crashes. `qmplay2-devel` works, but it's definitely not faster than my Plex player or a raw ffplay command - the audio is stuttery and fails to keep up, it jumps all over the place. Not sure if this is because I'm on Leopard.

I obviously have no way to compare anything to your Plex player; if it is better than everything else we got, that’s just awesome, we just need a local, non-server-dependent playback supported (if it is not supported yet).

I am genuinely surprised QMPlay2 works so horribly on your end, something must be wrong. I test it pretty regularly, though mostly -devel port. Can you give a specific example which works in ffplay but not in QMPlay2? I will try that.

In my opinion, these are not very complex applications - it doesn't take much effort to make a proper native Cocoa application that can build as a universal binary and optimize it directly with Apple APIs like CoreImage - to me this is a much better investment of my time that would give a more polished and optimized result. A bad player will amplify the codec problems but even with a very optimized player taking advantage of native Leopard APIs and C++ 20 features, threading etc, the codec problems are laid bare.

Well, outcome matters. If there is a Cocoa-based player supporting all codecs we need, no point to bother with fixing others.

 

[srp]

I obviously have no way to compare anything to your Plex player; if it is better than everything else we got, that’s just awesome, we just need a local, non-server-dependent playback supported (if it is not supported yet).

I am genuinely surprised QMPlay2 works so horribly on your end, something must be wrong. I test it pretty regularly, though mostly -devel port. Can you give a specific example which works in ffplay but not in QMPlay2? I will try that.



Well, outcome matters. If there is a Cocoa-based player supporting all codecs we need, no point to bother with fixing others.

Within the next couple of days you should be able to try this player and hopefully you will have good results with it! Obviously the kind of file you're going to be able to play with it depends heavily on your hardware - I get very good results on my Quad but my PBG64 is really best limited to 360-720p at max.

I was just testing and it can smoothly playback 360p on my PBG4 1.33 (10.6.8) in hardware mode. Software mode struggles, so machines without Core Image support may run into issues. Although this was designed as a Plex client specifically, I'm seeing now that it might be good to add some general purpose media player features.

I just tried to use QMPlay2 on the same PBG4 playing the same file - at first it wouldn't add my mp4 file because it's on an NFS share, so I had to copy it off onto my desktop, then the hardware renderer plays it but SLOWLY - using up around 90% CPU and only playing 2-3 FPS (OpenGL 2 activated, use PBOs where possible, VSync enabled), software mode plays it acceptably - about the same as the Plex player's hardware mode.

 

[barracuda156]

hnterm, new port, TUI for Hacker News:

 

[Andrew-R]

hnterm, new port, TUI for Hacker News:

View attachment 2603517

Highlighted news item is .... The Fire.
of course. I just use Discord for just one 3 person chat, but whole direction......